Over the years I've read dozens if not hundreds of blog posts about Kerberos and have always been left wondering.. what? And none of them have solved the cries of agony from Windows administrators and the "can't we just use NTLM?" crowd.
But today I found someone who actually understands the secret art of Kerberos on Windows! His name is Spencer Harbar and apparently he is a certified SharePoint Master, Microsoft's new certification for those with across-the-board understanding of SharePoint. His site is at http://www.harbar.net/ .
In truth, the key task in setting up Kerberos is understanding that your Kerberos settings should derive from your server and network topology design. Which users need access to which services? Which system accounts are communicating with which servers? What authentication mechanisms are supported by the systems under consideration? Once you have established the answers to these kinds of questions, implementing the solution is little more than a few setspn.exe commands away. If these haven't been considered in your design, this is what needs addressing before fiddling with setspn.exe .
Anyway, if you'd like to read more I recommend reading his posts about Kerberos, Understanding and Configuring Kerberos for you SharePoint environment, and checking out some powerpoint decks, in particular Kerberos Part 1 - Best Practices Slide Deck and Kerberos Part 2: The “Advanced” Scenarios .
I’m preparing a post about Active Directory Federation Services (ADFS) 2.0 and SharePoint 2010 Integration, to tie in to my previous claims based authentication article. Here’s a step by step guide to installing Active Directory Federation Services 2.0.
You can download ADFS 2.0 here: http://www.microsoft.com/downloads/details.aspx?FamilyID=118c3588-9070-426a-b655-6cec0a92c10b&displaylang=en
Installation went as follows, on a Windows 2008 R2 box. (This requires that Active Directory Domain Services is already up and running.)
Then the End-User License Agreement (EULA)
Now to choose between a Federation server and a Proxy. We want the first. The options are Federation server, which is the main server, and a proxy which is designed to sit on the barrier of a firewall and which talks to the main federation server. Microsoft describes the federation server proxy as "an authentication and trust management provider that issues security tokens to enable access to claims based applications in your organization or in federated partner organizations."
Installation of prerequisites follows. (Windows PowerShell, .NET Framework 3.5 SP1, Web Server IIS, and Windows Identity Foundation)
The installer then checks that prerequisites are installed.
.. and installs Windows Identity Foundation (WIF) and then AD FS 2.0.
Now that ADFS 2.0 is installed, you’ll need to reboot your computer. Once it starts up again, go to Server Manager by clicking Start->Administrative Tools->Server Manager . Select the Server in the left tree view and then, in the Roles Summary section, click “Add Roles”
After selecting Add Roles, click next then tick the Active Directory Federation Services role, then hit next.
For this tutorial we will install the Federation Service, which is the main AD FS service, and also the AD FS Web Agents: Claims-aware Agent and Windows Token-based Agent.
Now we need to configure a certificate.
What are certificates? Basically they work as a key that is used to mathematically prove that a server is who it claims to be and to encrypt traffic. Certificates, or at least some way of proving identity, are essential in establishing trust.
As is standard with SSL Certificates the subject name must match the host name. Generally on a public network (internet or cloud) you will want to use a certificate issued by an external certification authority (CA), while on internal networks you will want your own certification authority.
On the server I’m using, many already existed, but in a testing environment you may select to create your own.
Next we do the same for assigning a certificate for the purpose of Token-Signing . This is used to prove that generated tokens really were generated by a trusted federation server.
For the ADFS Web Agents we need to specify which federation server they should use. For this scenario I am pointing the Web Agents at the same server.
Now we need to create a Trust Policy, which defines what types of claims will be issued and accepted.
For this tutorial we’ll create a new Trust Policy, typically the step taken when creating a new farm.
Microsoft’s help files talk about using an existing trust policy across servers within a federation farm by placing the trustpolicy.xml in a shared folder secured through file system permissions. MS also cautions againt manually editing the file.
Finally we get a confirmation screen:
If all goes well, you’ll be presented with a successful installation results screen:
Now you can start configuring AD FS 2.0 in server manager. You may note the Active Directory Federation Services Role, in which you can configure the Federation Service, and the associated Trust Policy. It is broken into two elements:
- “My Organization”, which shows the Organization Claims, Account Stores, and Applications within your Organization; and
- “Partner Organizations” which is where you configure AD FS trust relationships.Including incoming and outgoing claims (Account Partners and Resource Partners)
- The default Organization Claims are Common Name, E-mail, and User Principal Name.
I'm digging around the newly-released SharePoint 2010 SDK. I'll put up a post in the near future summarising the changes to security, but in the meantime here's one change I noted: after (-ed) event receivers can now be run synchronously!
This resolves a common complaint about SharePoint 2007 after-event receivers, which ran asychronously, often resulting in a race condition, invalid data, and confused users.
It's implemented in the code used to bind the event receiver, and not in the event receiver itself. Basically the SPEventReceiverDefinition class includes a Synchronization attribute, which can be set to SPEventReceiverSynchronization.Synchronous or SPEventReceiverSynchronization.Asynchronous (or, finally, SPEventReceiverSynchronization.Default);
SPEventReceiverDefinition eventReceiver = eventReceivers.Add();
eventReceiver.Synchronization = SPEventReceiverSynchronization.Synchronous;
....
Beffore event receivers are still always run synchronously,as they can be used to cancel the action. If you needed to, you could always spawn a new thread within your synchronous event receiver)
The SharePoint Server and SharePoint Foundation 2010 SDK (Software Development Kit) has officially been released from Microsoft.
It's available at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=...
. Size is 324MB.
Fresh from the SharePoint designer team blog: SharePoint Designer 2010 has hit RTM, and is now available for download on Microsoft.com. It's available in 32bit and 64bit flavors.
Download links:
- x86 (32 bit) SharePoint designer RTM x86 free download
- x64 (64 bit) SharePoint designer RTM x64 free download
Price - still free!
Word on the street is that you'll probably want to run the 32bit version, and this goes for the recent Office 2010 RTM as well.

