Today's blog is about connecting Internet/Extranet users to a PerformancePoint solution that uses Kerberos delegation to pass end-user credentials through the application layers to back-end databases. This article is about how to do it in a way that doesn't require VPN deployment, is easy to use and convenient for end-users, and adds no additional burden on SharePoint administrators or DBAs.

What? Impossible you say?  Not at all.  In fact it can be relatively easy to implement without the commonly suggested security trap-doors.  The technique has really been around for quite a while, and it's accomplished through the use of a reverse-proxy solution such as Forefront TMG or ISA server (Forefront is the name of the latest version of the product formerly known as ISA Server).

The video below is an overview and demonstration of a working solution combining the following components.

1. Windows Server 2008 R2 x64
2. SharePoint Server 2010 (CTP)
3. PerformancePoint Services (part of SharePoint 2010)
4. SQL Server 2008 R2 (CTP)
5. Forefront TMG 2010

Note: You can view this video full screen by pressing the full screen button on the bottom toolbar. It's the second item from the right-hand side.

The following issue is a problem in SSAS that you might run into either in test or deployment environments (see references). 

In a nutshell, when a client session running Vista or Windows 2008 talks over the network to an SSAS server running on Windows 2008, and they use Kerberos for authentication, there likely will at some point be connectivity problems that resemble timeout or firewall blocking problems. 

Errors might look like one of the following:

The connection either timed out or was lost.
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
An existing connection was forcibly closed by the remote host

The two places we’ve observed these problems are:

1.       MDX queries submitted to the server that are reasonably large, such as those PPS submits, or perhaps those coded by hand that become large.  “Large” might be something like 1000 bytes or so.

2.       Deploying databases over the network from a Vista/2008 client to a 2008 server.

This problem still exists as of SQL 2008 SP1, so applying that update isn’t a resolution. This problem definitely exists when client & server are on different machines; may not be a problem when client/server are on the same computer (e.g. VPC or BIDS on a remote desktop session). 

From what I understand, MS is aware of this and we should expect a post-SP1 CU soon.  Whether this is to be resolved as a Windows patch or a SSAS patch is unclear to me. 

The following are work-arounds in the mean-time:

1.       If either the server or client is running XP or Windows 2003, the problem should not occur in any case.

2.       If you can edit the connect string (e.g. SSRS/Excel), specify ;SSPI=NTLM as a parameter.    Be advised that user security delegation will not succeed if this workaround is used.

3.       Connect with the IP address instead of machine name or FQDN.  Since Kerberos is unsupported with IP address connections, this also forces a fallback to NTLM.  Kerberos delegation also will not succeed when this workaround is used.

 Of particular note is that if SSAS is to be deployed on a Windows 2008 server, all available workarounds currently imply kerberos delegation will be impossible (a short-term driver for SSAS deployment on Server 2003?). 

 References:

http://blogs.msdn.com/psssql/archive/2009/04/03/errors-may-occur-after-configuring-analysis-services-to-use-kerberos-authentication-on-advanced-encryption-standard-aware-operating-systems.aspx

http://denglishbi.spaces.live.com/Blog/cns!CD3E77E793DF6178!1214.entry

http://sqlblogcasts.com/blogs/drjohn/archive/2009/03/28/kerberos-kills-large-mdx-queries-on-windows-server-2008-ssas.aspx

Just as with other BI front-end technologies in a Microsoft environment, Excel Services worksheets that access back-end data (e.g. Cubes, Databases) require Kerberos delegation configuration.  However, most MOSS installations are initially configured for NTLM security, and making the transition over to Kerberos becomes a challenge since all the things done by installer programs have to be done by hand.

 If you're trying to get your Excel Services worksheets to refresh to a back-end database and receive "Data Refresh Failed" error messages, odds are Excel Services hasn't been configured to delegate security. 

 1. Open Command Prompt
 2. cd C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN
 3. stsadm -o set-ecssecurity -accessmodel delegation -ssp SharedServices1
 4. stsadm -o execadmsvcjobs
 5. iisreset

In the interest of giving credit where due, thanks to Gunter Staes (http://blogs.msdn.com/gunterstaes) for the original command sequence some time back.

Recently I've been working on deployments of Windows Server 2008 and SQL Server 2008.  I thought I'd start to post some of the nuances of these new product editions. 

One of the first things to encounter is, not surprisingly, security.  Security is always loads of fun for deployments (ha ha), but actually I kind of enjoy the challenge of working within the confines of good security practices.

Windows Server 2008 is based on the Vista core, and inherits a lot from it.  One of these is the Windows Firewall.  I think this is a really good thing...having that extra layer of security is definitely wise, and is a nice blanket I actually miss from my Sun/Linux days--so I'm actually glad to have it there.  But, it also means you have to configure security for just about every new application, port, etc.

For SQL Server, this really isn't too difficult.  However since I do so many deployments, I'm always interested in a shortcut...and I like to document changes, get them approved by client syadmin, then apply them by script whenever possible. 

So, below is a sample script I put together for applying firewall changes needed by SQL Server 2008 when running on Windows 2008. This is a work in progress but so far so good. Note that this script opens just about every port SQL Server might use, so make sure to use only those lines that apply to any given server (e.g. don't open HTTP/80 if you're not running anything reporting services, etc.).

Of course, if you're using named instances for SQL Services, those instances by default will have dynamic (i.e. random) ports.  Dynamic ports don't work that well with a server firewall (and neither do they work well for Kerberos delegation configurations--but that's another topic).  So, a best practice is probably to set static ports for each instance and manage them that way.

One thing to make sure to do if using command lines like this is to specify rule names on the command line, then those names show up in the GUI-based firewall control panel (firewall.cpl)--see the screen grab down below. If you don't--then each rule will simply be named "unspecified"...not a nice thing to leave for the sysadmin to figure out later!

@rem firewallconfig.cmd by Rob Kerr 

@echo =========  SQL Server Ports  ===================
@echo Enabling SQLServer default instance port 1433
netsh firewall set portopening TCP 1433 "SQLServer"

@echo Enabling Dedicated Admin Connection port 1434
netsh firewall set portopening TCP 1434 "SQL Admin Connection"

@echo Enabling conventional SQL Server Service Broker port 4022 
netsh firewall set portopening TCP 4022 "SQL Service Broker"

@echo Enabling Transact-SQL Debugger/RPC port 135
netsh firewall set portopening TCP 135 "SQL Debugger/RPC"

@echo =========  Analysis Services Ports  ==============
@echo Enabling SSAS Default Instance port 2383
netsh firewall set portopening TCP 2383 "Analysis Services"

@echo Enabling SQL Server Browser Service port 2382
netsh firewall set portopening TCP 2382 "SQL Browser"

@echo =========  Misc Applications  ==============
@echo Enabling HTTP port 80
netsh firewall set portopening TCP 80 "HTTP"

@echo Enabling SSL port 443
netsh firewall set portopening TCP 443 "SSL"

@echo Enabling port for SQL Server Browser Service's 'Browse' Button
netsh firewall set portopening UDP 1434 "SQL Browser"

@echo Allowing multicast broadcast response on UDP (Browser Service Enumerations OK)
netsh firewall set multicastbroadcastresponse ENABLE

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:

1. A single database server running SQL Server and Analysis Services (BI-DB).
2. An application server hosting PPS Monitoring Server, ProClarity Analytics Server and Reporting Services (BI-APP)
3. 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:

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:

1. Launch Active Directory Users and Computers.  Find the PPS server (BI-APP for us) in the list, double-click it.
2. Click on the delegation tab. 
3. Select the third option, Trust this computer for delegation to specified services only
4. Click the Use Kerberos Only radio button
   
5. Click the Add button
6. 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). 
   
7. 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.
8. With MSSQLSvc added to the Delegation tab of the BI-APP machine account, press OK on this dialog to save the delegation settings.
   
9. 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:
   
10. 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:
    
11. Again, the same sequence for BI-WEB’s service account (svc_bi_web), yielding the following configuration:
    
12. 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.
13. Navigate within ADSIEdit to find the computer account for the APP server (BI-APP for us). 
14. Right-click on the computer, choose Properties.
15. In the Attribute Editor, locate the string msDS-AllowedToDelegateTo, and click the Edit button.
16. 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:
    
17. 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.
18. Repeat this change for the web server as well (BI-WEB in this example)
19. 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.

Microsoft’s security focus over the last few years has brought many improvements in the overall level of security.  Along with this level of security also comes an increasing number of hoops to jump through to accomplish simple tasks.

Recently I found that it became impossible to install software from network shares onto Windows 64-bit servers.  Trying to do so resulted in the error message:

“Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.”

Searching on the Internet, the most commonly suggested workaround I found was to uninstall the Internet Explorer Enhanced Security Configuration from the computer.  This actually does work, but really doesn't sound like a great solution to me. 

As it turns out, the solution is quite simple...but also a bit of a head scratcher.  You wouldn’t think accessing files on your LAN would be controlled by an Internet Explorer setting (well maybe you would, but I wouldn’t!).  Yet, changing IE settings is the easy way to solve this problem.

The solution is to add the LAN server where your install source share is to the Local Intranet zone in Internet Explorer.  I suppose adding to the Trusted Sites would probably work, but since a share location is in the intranet for most of us, I think that’s the more logical place to make this change.

Here’s how I solved it on a 64-bit Windows 2003 R2 server with SP2 and IE7:

1. In Internet explorer, select Tools/Options, then click on the Security tab
2. Select the Local Intranet icon, then press the Sites button
   
   
   
3. In the Add this website to the zone textbox, enter the name of the server in the form file://servername, then click the Add button
   
   
4. Click the Close button on the bottom of the dialog, then OK on the Internet Options dialog

With that change made, your server should now be able to run software from network locations.  No more need to copy them to a local file location first!

In this article I'll provide some basic guidelines for implementing X.509 PKI-based e-mail encryption that you can implement for free!  The goal for this article is a process you can use with your business associates and/or friends to exchange e-mail securely, with no additional software to install, and no costs to anyone in the process.  Sounds too good to be true?  Not at all!

Usually we send e-mail over public networks--via ISPs that guarantee no level of confidentiality.  We've probably all received passwords or other sensitive information via Internet e-mail at some time in the past.  Have you ever thought to yourself, "wouldn't it be great if I could easily send this e-mail in a way that only the recipient could read it?" 

Probably the most popular mechanism for sending encrypted is the proprietary--and until recently free--PGP client software.  I've long been a fan of PGP, which is not just good for e-mail privacy, but also for transmitting data securely.  But for e-mail encryption, PGP is traditionally a little nerdy to use, and I can't say I've ever had a business contact ask me to send him or her a PGP key.  The newer commercial versions of PGP clean up the clunkiness quite a bit, but installing PGP client software is a big step, may be prohibited by company policy, and even though $99/user isn't going to break the bank, a free alternative would be easier, right?

 X.509 Public Key Infrastructure (PKI) based encryption has been available for years, but in my experience is rarely implemented.  Perhaps the primary reason is complexity, low perceived need-level and/or inconvenience. 

Recently I took a look at using X.509 PKI keys in conjunction with Outlook 2007, and I was amazed at how simple it was to implement--at least at an informal peer-to-peer level. Although I'm using Outlook 2007, the ability to use certificates to send/receive encrypted e-mail isn't new with the 2007 version, and this basic approach will work with virtually any Microsoft e-mail client, and in fact most other e-mail clients as well.

Let's look at how to implement this solution. Setting up X.509 within Outlook 2007 has a few requirements:

1. Both the sender and receiver need public/private key pairs from a trusted Certificate Authority (CA).
2. Each party must have the private key installed on their own Windows PC
3. Each party must have the public key for the other party in his/her local certificate store 

Once everything is setup, the process is really pretty simple:

1. The sender uses the recipient's public key to encrypt the e-mail message as it's sent
2. The receiver uses his/her own private key to decrypt the message

We'll return to getting "everything setup" in a minute, but first a little bit more about why this process works... 

PKI e-mail certificates work because anyone can encrypt a message using the recipient's public key, but only the recipient's private key can reverse the process--yielding a decrypted message.  So the public key can be distributed to anybody without compromising the solution.  Only the accidental release of the private key will compromise the security of the transaction.  If this sounds like SSL (the technology used to encrypt your credit card on amazon.com), that's because it's almost exactly the same.

So, you ask, does that mean I have to buy an SSL certificate for my e-mail program--just like I do for my web servers--and all my e-mail recipients have to do the same?  Well, yes--and no.  Just as with SSL certificates, anyone can issue them.  You could create your own certificate, and your associates could create their own as well. The problem is that if you issue your own certificate (i.e. you become your own CA), you need to convince everyone you send e-mail to to trust your self-signed certificates.  Actually it's not your friends you need to convince--it's their computers. 

So, for self-signed certificates to work seamlessly, you'd have to get all your recipients to install your root certificate into their computer.  This is a reasonable thing to do if all users sending/receiving e-mail are within your company, but when it comes to external recipients, self-signed certificates may well be impractical. Just as with web site SSL certificates, it's easier to use a commercial CA that everyone else already trusts.

So, to exchange e-mail securely with external associates, the best option is to use certificates issued by a commercial, trusted CA.  These certificates are fairly inexpensive, and can even be obtained for free from Thawte and Comodo.  There are some good reasons to buy blocks of certificates from these companies and roll them out in your company.  However, for our informal solution, we'll just use free certificates from Comodo. 

OK, enough background.  Let's get this implemented.  Here's the process:

1. Go to Comodo's web site, and obtain a free secure e-mail certificate.  Just follow the instructions (which I won't go through completely here).  At the end of the process, the certificate will be installed in the certificate store on your Windows PC. 
2. Have the intended recipient(s) of your encrypted e-mail also obtain secure e-mail certificates.  It doesn't matter whether everyone uses the same provider (Thawte, Comodo, Verisign, etc.).
3. Send each of your intended recipient(s) a signed e-mail.  This is easy to do--just click the "Digitally Sign" button in the Outlook 2007 Options ribbon bar section.  Your recipient(s) should also send you a signed e-mail button.
4. Sending the signed e-mail messages is just a way to exchange public keys (remember, you need to have the recipient's public key to encrypt a message before sending it to him/her).
5. When you receive a Digitally Signed e-mail, right click on the 'From:' e-mail address, and add the contact to Outlook.  If your recipient's contact information is already in Outlook, accept Outlook's warning and let it update contact information. This will add the public key to the existing contact record.  Your recipient should do the same with your signed e-mail so he/she can encrypt e-mails for you.

Now that you have your recipient's public key, and your associate(s) have yours, all you have to do is click on the "Encrypt" button in the Outlook 2007 Options ribbon bar section before you send the e-mail.

That's it! Now you and your associates can send encrypted e-mail to each other anytime you want.  In fact, it's so seamless you probably won't even be aware that the e-mail you receive is encrypted--Outlook will automatically decrypt e-mail for you as you read it.  If you want to verify that the process is actually working (and of course you do!), there are two simple ways to know a received e-mail is encrypted:

First, the e-mail reading window will have one or two icons: the first looks like a padlock, and indicates the message is encrypted.  The second looks like a 4-H ribbon, and indicates the message is signed.  These are the same icons used in the Outlook tool-bar.

The second clue that a message is encrypted is that Outlook can't display it in the preview pane:

Now that your certificate is installed, whenever you have a request to send or receive encrypted e-mail with an external associate, simply exchange public keys (by sending digitally signed messages to each other), and you're on your way!