Configure MS Dynamics CRM 2011/2013/2015 to use multiple Report Servers (SSRS)

This week I've had quite a bit of fun turning the resilience up to 11 for our production environment of MS Dynamics CRM 2013.

In this post I will discuss how to configure Ms Dynamics CRM 2013 to use multiple SSRS servers, thus ensuring that reporting functionality is as resilient as the rest of the system.

In order to achieve this we need to make changes to AD, the SSRS configuration and finally MS Dynamics CRM. 

It's worth pointing out that this could well be overkill for your system, and to a certain extent it is for ours, but the whole architecture must be resilient is the diktat from above so ...

Pre-Requisites:

• 1 x Load Balancer (Distributing traffic to SSRS Servers on correct port, normally 80).
• 1 x VIP.
• 1 x DNS Record (For VIP above).
• 2+ x SSRS Servers in a scale out deployment.
• SSRS configured to use a domain account.
• Permissions to set SPNs on your domain and edit at least ssrs service account.

My Setup:

DNS record is: CRMReports.dev.local
SSRS Service Account:  dev\svc-ssrs

1. Active Directory

The first thing to do is to set up an Service Name Principal for the account that's running the SSRS service, which can be done with the following commands:

setspn -S HTTP/<VIP FQDN> <SSRS Service account>
setspn -S HTTP/<VIP Name> <SSRS Service account>

So in my case:

setspn -S HTTP/CRMReports.dev.local dev\svc-ssrs
setspn -S HTTP/CRMReports dev\svc-ssrs

The next thing is to ensure that the account is enabled for delegation, so from Active Directory Users and Computers console.

Note that the delegation tab will only appear after an SPN has been set up for that account.

2. SSRS

The first thing to do in the report server, is to enable Kerberos authentication, which can be done by editing the rsreportserver.config file. This file is normally found in this directory: C:\Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\ReportServer\

Look for the Authentication section and enable Kerberos and Negotiate as below (I've commented out NTLM in case I wanted to go back)

<Authentication>
  <AuthenticationTypes>
   <RSWindowsKerberos/>
   <RSWindowsNegotiate/>
   <!--<RSWindowsNTLM/>-->
  </AuthenticationTypes>
  <RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>
  <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>
  <EnableAuthPersistence>true</EnableAuthPersistence>
 </Authentication>

From the Reporting Services Configuration Manager, Click on Web Service URL and then click on Advanced

Click on Add as highlighted.

Enter the host header name, which will be the DNS Record for the VIP, in my case: crmreports.dev.local and click OK to accept.

Repeat this process for the Report Manager Url.

Once done repeat all steps on section 2 on the other report servers.

3. MS Dynamics CRM

The process is relatively simple and it involves editing the organization to point to the new report server dns, i.e. crmreports.dev.local in my case.

From the Deployment Manager, select organization and Disable your organization(s).

Click Edit Organization.

Set the new report server Url.

 Ensure that all checks are ok.

Congratulations, you now have a resilient reporting service for MS Dynamics CRM.

Easily Generate Required SPNs for MS Dynamics CRM 2011

I've not had a chance to try this yet, but it seems like it could save a lot of time.

Easily Generate Required SPNs for CRM 2011

Configure system to authenticate using Kerberos

This objective is not very well defined or at least I don't understand what Red Hat is aiming at here.  There is no mention of using Kerberos for anything once the system is configured to authenticate with Kerberos or what directory service should be used for accounts or indeed whether a directory server should be used at all. The other issue that I see, is the fact that you need user principals to be able to do anything, you might be supplied these in the exam, who knows?

Anyway, assuming that you have a working KDC server, see my post on openSSH with Kerberos for details of configuring a KDC, you can use authconfig-tui to configure Kerberos on your client.

You can then check the /etc/krb5.conf file should now be modified to:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = DOMAIN.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 DOMAIN.COM = {
  kdc = yetanother.domain.com
  admin_server = yetanother.domain.com
 }

[domain_realm]
 .domain.com = DOMAIN.COM
 domain.com = DOMAIN.COM

Unfortunately, this will not actually do much.

kinit
kinit: Client not found in Kerberos database while getting initial credentials

As mentioned above you need a user principal in order to get a ticket and a user to be able to do anything useful. Let's say that you have openLDAP configured (have a look at this post if in doubt) and you have a user account called crap in that domain. Assuming that a principal for crap exists and you know the password you can just do:

kinit crap

and provided that you typed the right password, you'll get a ticket, check with:

klist

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: crap@DOMAIN.COM

Valid starting     Expires            Service principal
06/17/11 11:59:53  06/18/11 11:59:53  krbtgt/DOMAIN.COM@DOMAIN.COM
        renew until 06/17/11 11:59:53

Have a look at my previous post to configure openSSH to work with Kerberos.

Use Kerberos to authenticate OpenSSH - RHEL6

In order to achieve this you'll need two machines. They can be VMs or actual physical boxes. Ideally, you want to set up Kerberos in conjunction with an LDAP Directory, Windows Active Directory will do just that and I plan on investigating how to get single sign-on working with a Windows AD domain, but in actual fact, you don't need an LDAP directory, you can just as easily use local users, but I'm getting ahead of myself.

In order to make my life easier, I have created a new zone in my DNS server, called domain.com, and I have added both the kdc server and the client to this zone. I then edited the /etc/resolv.conf file to point to my DNS server. This is actually not needed and you can use the /etc/hosts file instead, just make sure that you have entries for both the kdcserver and the client on both the kdcserver and the client. Also make sure that the entries are of the form:

ipaddress fqdn hostname

In my case the kdc server is called yetanother.domain.com and the client another.domain.com, so bear that in mind, when running through the instructions.

Logged in as root on  yetanother.domain.com run:

1. yum install krb5-server -y  -- To install the KDC
2. kdb5_util create -s -- To create the KDC database.
3. edit /var/kerberos/krb5kdc/kadm5.acl and change the Realm to DOMAIN.COM -- To enable administration of the database.
4. edit /etc/krb5.conf and change references to example.com to domain.com. Note that you should respect capitalization, e.g. EXAMPLE.COM should be changed to DOMAIN.COM and example.com should be changed to domain.com -- This is the client configuration.
5. kadmin.local -q "addprinc root/admin" -- add an administrator to kdc.
6. service krb5kdc start -- self explanatory.
7. service kadmin start -- self explanatory.
8. kadmin.local -q "addprinc -randkey host/yetanother.domain.com" -- add kdc principal to kdc.
9. kadmin.local -q "addprinc -randkey host/another.domain.com" -- add client principal to kdc.
10. ktutil. While on ktutil shell: ktadd -k /etc/krb5.keytab host/yetanother.domain.com -- add kdc principal to keytab file.
11. Add a principal that corresponds to a user account. kadmin.local -q "addprinc crap" -- add a user.
12. Ensure that  the openSSH daemon will accept GSSAPI as an authentication method. Make sure that the following lines are not commented out. -- Configure the openSSH daemon.
    

    GSSAPIAuthentication yes
    GSSAPICleanupCredentials yes

13. service sshd restart --Restart the openSSH daemon.

If you are not using an LDAP directory for user accounts, make sure that the user crap exists in both server and client.

Logged on as root in another.domain.com, ensure that the date and time are the same as on yetanother.domain.com and run:

1. ktutil. While on ktutil shell: ktadd -k /etc/krb5.keytab host/another.domain.com
2. Add the following lines to the ssh client config file (etc/ssh/ssh_config).
   

   Host *.domain.com
   GSSAPIAuthentication yes
   GSSAPIDelegateCredentials yes

3. Ensure that the /etc/krb5.conf file is identical to the one in yetanother.domain.com
4. su crap
5. kinit -- Get a kerberos ticket.
6. ssh yetanother

This will log you in to yetanother.domain.com as the user crap.

In general, it makes sense to use an LDAP directory together with Kerberos authentication as otherwise you will need to have a user account in each server. So that I would have needed to add a user account called crap to another.domain.com. This is not a very onerous task, but if you have to do it for many servers it gets boring quickly.

To add more servers simple create a principal for the server (kadmin -q "addprinc -randkey host/servername.domain.com"), then add that principal to the krb5.keytab of the server (servername.domain.com) by running: ktutil. While on ktutil shell: ktadd -k /etc/krb5.keytab host/servername.domain.com. Make sure that the kerberos configuration file /etc/krb5.conf is correct and finally make sure that the openSSH client and daemon are configured correctly, see above.