CRM maakt gebruik van Kerberos als authenticatie provider. Op het moment dat je CRM installeert wordt automatisch Kerberos aangezet en dit zorgt ervoor dat je kunt aanloggen en functionaliteiten gebruiken van CRM zonder dat je je keer op keer opnieuw hoeft aan te melden.
Waarom Kerberos? Kerberos is op dit moment de meest veilige standaard authenticatie provider. Ook wel de drie koppige draak genoemd omdat het authenticatie mechanisme over 3 schijven gaat. De Griekse Mythe vertelt dat de drie koppige draak Kerberos niet was te verslaan.
Is er een alternatief voor CRM authenticatie? Ja en Nee. Officieel is er geen supported alternatief, maar in de praktijk zien we door allerlei Kerberos problemen dat het fall-back scenario NTLM wordt gebruikt. Dit staat standaard ook aan op de CRM applicatie server, maar het zou kunnen zijn dat bepaalde functionaliteit van CRM niet werkt, bijvoorbeeld rapportage. Of dit zo is, hangt helemaal af van de wijze waarop CRM is geïmplementeerd.
Is NTLM niet goed genoeg? Met de tegenwoordige kennis en tooling is NTLM authenticatie eenvoudig af te luisteren met alle gevolgen van dien. Dus het antwoord in het huidige tijdperk met de roep om betere security is NEE.
Zijn er problemen met Kerberos? Nou, Kerberos werkt alleen goed als het op de juiste manier is geconfigureerd. De infrastructuur vereist dat je een aantal zaken goed moet configureren om Kerberos zijn werk te laten doen. Als je dit niet doet, of niet goed doet dan ervaar je binnen CRM problemen met authenticatie via Kerberos.
CRM werkt, hoe weet je dat je een Kerberos probleem hebt? Kerberos kun je niet half gebruiken. Het werkt of het werkt niet. Echter CRM is vaak zo geconfigureerd dat er onder water alsnog een ander type authenticatie wordt gebruikt waardoor je niet meteen merkt of je wel of geen Kerberos gebruikt. Dus waar we naar opzoek zijn is een bevestiging of Kerberos daadwerkelijk gebruikt wordt voor CRM. Kijk hiervoor in de Event Viewer op de CRM applicatie server of Kerberos wordt gebruikt door in het security log te kijken naar de regel waar je aanlogt (even zoeken op je user naam) en dan te kijken bij het veld: Authentication Package. Als hier Kerberos of Negotiate staat dan is dat de bevestiging waar we naar opzoek zijn. Staat hier NTLM dan is dat niet goed.
Hoe kan ik dieper onderzoeken of Kerberos wordt gebruikt? Gebruik hiervoor netwerk tracing tools als Netmon en Fiddler. En zoek naar de eerste communicatie tussen de client en de server. Hier wordt absoluut aangegeven welke authenticatie provider wordt gebruikt (NTLM of Kerberos).
Hier een heel goede blog over de verschillende scenario’s met configuraties die daarbij horen.
Via de volgende symptomen probeer ik inzicht te geven in het type configuratie dat gedaan moet worden om Kerberos authenticatie problemen op te lossen.
Symptoom 1.
Je verwacht dat Kerberos ervoor zorgt dat je direct kan aanloggen aan CRM, maar in plaats daarvan krijg je een inlogbox (Authenticatieprompt).
Oorzaak symptoom 1
De URL van CRM staat niet in de Local Intranet zone van Internet Explorer. Standaard zal Internet Explorer vanuit beveiligingsoogpunt uitsluitend de credentials van de gebruiker naar een CRM server sturen wanneer deze in de Local Intranet zone staat.
Het standaard gedrag van Internet Explorer is dat wanneer er één of meerdere punten in de URL staan, de URL als Internet (lees: non-trusted) wordt gezien en daardoor niet de credentials van de gebruiker ongevraagd meestuurt.
Oplossingen symptoom 1:
1. Gebruik een URL zonder punten
2. Voeg de URL toe aan de Local Intranet zone binnen Internet Explorer
Dit kan eventueel via een groepspolicy centraal geregeld worden.
Let op: standaard zullen de credentials van de aangelogde gebruiker naar de CRM server gestuurd worden wanneer deze onder de Local Intranet setting valt. Dit kan echter gewijzigd zijn en dient daarom gecontroleerd te worden.
Symptoom 2
Ondanks dat bovenstaande instelling correct staat, krijgt de gebruiker geen toegang tot de CRM applicatie.
Oorzaak symptoom 2
In veel gevallen wil Kerberos niet werken omdat één of meerdere benodigde Service Principal Names (SPNs) ontbreken. Kerberos authenticatie is afhankelijk van SPNs. Wanneer een gebruiker naar CRM connecteert, zal Kerberos zoeken naar de SPN van de betreffende service; de CRM applicatie URL in ons geval. Kan deze SPN niet gevonden worden, dan zal Kerberos falen en er eventueel terug gevallen worden op het zwakkere NTLM authenticatie protocol.
Maar een verlopen wachtwoord van het CRMApppool useraccount of een gedisabled CRMApppool useraccount is ook een mogelijke oorzaak.
Oplossing symptoom 2
Verifieer dat de benodigde SPNs aanwezig zijn en creëer de ontbrekende SPNs. Via het commando SetSPN –L kan je een SPN opvragen en middels SetSPN –A kan je een SPN creëren.
Let op 1: je dient domein beheerder rechten te hebben om een SPN te mogen/kunnen maken.
Let op 2: SPNs moeten uniek zijn. Er mogen dus geen dubbele SPNs aanwezig zijn.
Symptoom 3.
Je kan zonder hiervoor geprompt te worden succesvol connecteren naar de CRM applicatie, maar de applicatie werkt niet volledig; e.g. je kan geen rapport draaien.
Oorzaak symptoom 3
Dit symptoom kan meerdere oorzaken hebben:
1. De CRM applicatie wil jouw credentials gebruiken om naar de backend server te connecteren (e.g. de report server). Hiervoor dient het account waar de ApplicatiePool onder draait vertrouwd te zijn om jouw credentials te delegeren. Wanneer dit account hier niet toe vertrouwd is, zal de connectie falen.
2. Kernel Mode Authenticatie wordt gebruikt, maar de useAppPoolCredentials staat op False.
Oplossingen symptoom 3
1. Vertrouw het account waar de applicatiepool onder draait om credentials te delegeren door het ‘Trusted for delegation’ te configureren.
Dit kan middels ADSIEdit.msc maar ook via de AD Users and Computers interface
2. Zet de useAppPoolCredentials instelling op True
Symptoom 4.
Er wordt gebruik gemaakt van meerdere applicatie servers met meerdere CRM Apppool useraccounts via een loadbalancer
Oorzaak symptoom 4
De CRM applicatie wordt gehost vanuit meerdere applicatiepools. Deze dienen onder één en hetzelfde account te draaien, aangezien SPNs uniek dienen te zijn en daarmee aan slecht één enkel account gekoppeld kunnen worden.
Oplossingen symptoom 4
Configureer elke applicatiepool die via dezelfde URL opgevraagd wordt, met hetzelfde service account.
Symptoom 5
Voor de CRM omgeving wordt 1 URL gebruikt die naar de CRM server (of loadbalancer) wijst. Echter deze is geconfigureerd met een alias.
Oorzaak symptoom 5
Omdat er gebruik gemaakt wordt van meerdere frontend CRM webservers, wordt er een load balancer gebruikt. De URL van de CRM webapplicatie dient hierdoor naar de load balancer te resolven. Wanneer dit middels een alias (CNAME) record gebeurt, kan dit afhankelijk van de browser versie de Kerberos authenticatie doen falen. Sommige browser versies zullen namelijk een SPN gaan zoeken voor het host (A) record van de load balancer, en deze zal waarschijnlijk niet aanwezig zijn.
Oplossingen symptoom 5
GA naar de DNS server en verwijder de CNAME. Gebruik altijd een host (A) record in DNS om de URL van de CRM webapplicatie te resolven. Wanneer er vervolgens (zoals hierboven beschreven) een SPN voor deze URL is, zal Kerberos authenticatie werken.
Hierbij wil ik mijn collega Dirk-Jan van der Vecht bedanken voor het mede opstellen van deze post.
Succes!
In mei 2011 is het MSCRM 2011 Client Performance Whitepaper gereleased. En vandaag, december 2011 is daar een refresh van uitgebracht. Waarom is dit een belangrijk Whitepaper?
In vele CRM projecten worden performance optimalisaties gezien als activiteiten die pas nuttig zijn aan het eind van het project (wanneer de performance wordt getest). Of nog erger, pas na de go-live van de CRM applicatie.
Het probleem is dat functionaliteit in tegenstelling tot performance hoger op de prioriteitlijst staat van het project. Redelijk logisch want als je de functionaliteit niet kan leveren waar de gebruikers om vragen, dan wordt de CRM applicatie uiteraard niet in gebruik genomen. Maar als de functionaliteit wel geleverd kan worden, maar het performed niet, dan wordt de CRM applicatie ook niet in gebruik genomen. Maar waar zit de valkuil nu?
Vaak worden de functionaliteits tests uitgevoerd zonder dat hier de performance in wordt meegenomen. Er wordt dus uitsluitend gekeken of iets werkt en niet hoe lang het duurt om de bewerking te voltooien. Het voordeel (voor het project) is dat deze tests vaak op kleine schaal worden uitgevoerd en de performance problemen dus nauwelijks zichtbaar zijn omdat:
1. De dagelijkse load van de pc niet op een test pc voorkomt
2. De servercapaciteit vaak groot genoeg is om deze kleine load op te vangen
3. Performance niet wordt gemeten tijdens de tests, en er daardoor geen inzicht is van de performance getallen die een gewone user genereert bij normaal gebruik.
Is dit een probleem? JA! Een voorbeeld: Er wordt in een scherm een bepaalde functionaliteit in gebouwd die ervoor zorgt dat data real-time wordt opgehaald uit een ander systeem. Vervolgens worden er aanpassingen gedaan in het scherm waarna het record wordt opgeslagen in CRM. Na deze actie worden er workflows gestart die het opgeslagen record gebruiken als trigger, bijvoorbeeld om terugbel acties te plannen, andere gebruikers te informeren, validatie checks uitvoeren, Audit records opslaan, noem maar op. In je eentje of met een paar mensen is dit niet zo’n probleem. Maar ga je zulke acties met 1000 man tegelijk doen dan wordt het allemaal een ander verhaal.
Oplossing? Eenvoudig. Zorg ervoor door de juiste vragen te stellen dat je vanaf de start van het project begrijpt welke performance impact een bepaalde business requirement kan hebben. Probeer deze in getallen om te zetten zodat het meetbaar wordt. Beperkt de variabele (onzekere) factoren en stel vervolgens de meetmethode vast. Gebruik die kerngetallen om deze om te rekenen naar het concurrent aantal gebruikers.
Een Voorbeeld:
1. Business Requirement – Eenvoudig een lead omzetten naar een opportunity of klant
2. Beoogde performance impact:
Functionele vragen: Hoe vaak komt dit voor? Hoe vaak is dit voorgekomen in de afgelopen periode? Welke acties zitten hier aan vast? Adres validatie? Krediet Check? Audit? Worden andere applicaties gebruikt tijdens deze activiteit? Master Data Management? Welke gebruikers doen deze actie? Etc.
Technische vragen: Hoeveel velden worden ingevuld of aangepast? Hoeveel entiteiten worden geupdate? Hoeveel indexen en views worden met deze actie geupdate? Welke hoeveelheid data wordt er uitgewisseld? Etc.
3. Maak van deze vragen getallen, bijvoorbeeld:
- Hoe vaak komt dit voor? gemiddeld 10 x per dag, max 100 x per dag per gebruiker.
- Welke acties? Opslaan in applicatie, update financieel systeem, synchronisatie outlook.
- Welke gebruikers? Alleen het sales team.
- Hoeveel velden? Maximaal 120, 10 integer, 10 bitvelden, 30 lookups, 50 picklists, 20 textvelden
- Hoeveel Entiteiten, indexen, views? 8 entiteiten, 40 indexen, 5 views
- Hoeveel data? 800Kb naar de server, max 5mb wanneer een attachment wordt mee gesaved.
NB. Dit lijstje kannog worden uitgebreid met het aantal server requests, roundtrips, etc.
4. Maak deze getallen meetbaar, bijvoorbeeld:
CRM server monitoring, IIS logging, SQL logging. Eventueel uitbreiden met custom tools zoals de performance toolkit
Bijkomende voordelen:
1. De impact van het in gebruik nemen van nieuwe functionaliteit is direct inzichtelijk
2. Ervaring met monitoring tools kan gelijk worden opgebouwd en gedocumenteerd
3. Inzichtelijk wat het verschil is tussen verschillende hardware en software configuraties
Succes!