In a Microsoft BI environment, we very often want to grant data visibility permissions at the datebase level. The most common way to accomplish this is to use Kerberos delegation.
In Active Directory, delegation comes in two flavors: Constrained and Unconstrained. Constrained delegation provides an enhanced level of security for deployments where Kerberos delegation is used to pass end-user credentials to back-end services.
In an unconstrained delegation configuration, servers and service accounts are trusted to send Kerberos tickets to any service on any destination computer. This typically isn’t a problem, since administrators know what their service accounts are used for, and what software is installed on their servers.
However, using constrained delegation provides an additional level of security by restricting which back-end services on which destination server a computer account or service account may pass Kerberos tickets to. Constrained delegation satisfies the “principle of least privilege”, where even trusted principals are granted only the minimum permissions needed to get their job done.
Promoting delegation from unconstrained to constrained delegation is relatively simple. This additional level of security isn't without cost, however. Following a constrained model will result in additional long-term administration (the addition of a new back-end web server or database will require additional Active Directory configuration). However, if the least privilege principle is the best practice in your company, constrained delegation is for you.
The following process goes through constrained configuration of a typical distributed Microsoft BI environment. This process assumes you’ve already configured an unconstrained Kerberos delegation environment. The following only covers the upgrade to constrained delegation.
In the following scenario, there are:
- A single database server running SQL Server and Analysis Services (BI-DB).
- An application server hosting PPS Monitoring Server, ProClarity Analytics Server and Reporting Services (BI-APP)
- Finally there is a SharePoint server (BI-WEB).
Services on each server are run using the service accounts svc_bi_db, svc_bi_app, and svc_bi_web, respectively.
First the documentation. Don’t skip this step! The key to completing this process successfully is organization, because any mistake may cause integrated authentication to fail and the troubleshooting will be difficult and even more time consuming! You need to know what service accounts are running each service on every server, and use this information to make Active Directory configuration changes.
Documentation is a two-step process: document delegation trusts needed for each server, then the trusts needed for each service account. If you’ve already setup your basic Kerberos delegation using SetSPN or ADSIEdit, you should have this information handy.
The following are the trust requirements for our scenario:
Table #1 - Computer Delegation Trusts
|
Delegator
(Computer) |
Delegatee
(Service Account) |
Allowed Destination
(service/server:instance) |
| BI-APP |
svc_bi_db |
MSOLAPSvc.3/BI-DB:PROD
MSSQLSvc/BI-DB:1433 |
| BI-WEB |
svc_bi_db
|
MSOLAPSvc.3/BI-DB:PROD
MSSQLSvc/BI-DB:1433
|
| BI-WEB |
svc_bi_app |
HTTP/BI-APP |
|
Table #2 - Service Account Delegation Trusts
|
Delegator
(Service Account) |
Delegatee
(Service Account) |
Allowed Destination
(service/server:instance) |
| svc_bi_app |
svc_bi_db |
MSOLAPSvc.3/BI-DB:PROD
MSSQLSvc/BI-DB:1433 |
| svc_bi_web |
svc_bi_db
|
MSOLAPSvc.3/BI-DB:PROD
MSSQLSvc/BI-DB:1433
|
| svc_bi_web |
svc_bi_app |
HTTP/BI-APP |
|
With this information, we’re ready to make the Active Directory changes. These changes are mostly made in the Active Directory Users and Computers snap-in, however we’ll see that the named instance used for the OLAP server isn’t supported by this snap-in (I don't know whether this is a bug or the intended behavior, but you can read about it in Microsoft knowledge base article 936628). We'll work around this limitation by making the final configurations in the ADSIEdit snap-in.
First let’s take care of the machine account configurations:
-
Launch Active Directory Users and Computers. Find the PPS server (BI-APP for us) in the list, double-click it.
-
Click on the delegation tab.
-
Select the third option, Trust this computer for delegation to specified services only
-
Click the
Use Kerberos Only radio button
-
Click the Add button
-
In the
Add Services dialog, click the
Users or Computers… button, then enter the service account used to run the database services on the database server (the second column in table #1).
-
In the Add Services dialog, we need to select all the services in the third column of table #1 (MSSQLSvc/BI-DB:1433 and MSOLAPSvc.3/BI-DB:PROD in this example), then click OK. Note that if your OLAP database is a named instance (as ours is), then only MSSQLSvc is available…this is because this snap-in doesn’t work for named OLAP instances. We’ll get around this problem later using the ADSIEdit snap-in.
-
With MSSQLSvc added to the Delegation tab of the
BI-APP machine account, press
OK on this dialog to save the delegation settings.
-
Repeat the same sequence for the
BI-WEB server, but this time in addition to adding services for the account
svc_bi_db, also add services for the
svc_bi_app account to allow delegation of security for
HTTP services to that machine. When you’re done, the computer account delegation tab for
BI-WEB should look like this:
-
Repeat the same sequence for
BI-APP’s service account (
svc_bi_app) using the values in columns 2 & 3 of table #2, yielding the following configuration when complete:
-
Again, the same sequence for
BI-WEB’s service account (
svc_bi_web), yielding the following configuration:
-
If your OLAP database has no instance name (you're using the "default instance"), you’re done! If not, you’re almost finished, except that the
Active Directory Computers and Users snap-in doesn’t support the named instance of the OLAP database. So, open the
ADSIEdit snap-in (
adsiedit.msc) instead.
-
Navigate within ADSIEdit to find the computer account for the APP server (BI-APP for us).
-
Right-click on the computer, choose Properties.
-
In the Attribute Editor, locate the string msDS-AllowedToDelegateTo, and click the Edit button.
-
Add two values for the OLAP database used in your environment (
MSOLAPSvc.3/BI-DB.terrafirma.kerr.cc:PROD and
MSOLAPSvc.3/BI-DB:PROD for our example). Note that the two are the same except one has the FQDN and the other has only the NetBIOS name of the server. Both are required. When finished, the string editor should look like this:
-
Click OK, on the string editor, then OK on the machine properties to save changes. If you return to this editor in ADSIEdit, you can review and update these chnages. However, beware that if you review changes in the Active Directory Users and Computers snap-in, you won't see these named instance entries.
-
Repeat this change for the web server as well (BI-WEB in this example)
-
Repeat this change for the user accounts used on the BI-WEB and BI-APP servers (svc_bi_web and svc_bi_app in this example).
OK, that’s all. Now the environment is configured for constrained delegation. From this point on, AD will still allow Kerberos delegation as before, except now it will carefully check not only that service accounts are running on the machine they should, but also that each service account is only passing tickets to servers/services that are pre-authorized.