Connect.Collaborate.SharePoint
Jun
18

It seems that I have a different experience every time I install this configuration.

A few key points if you are thinking of doing this:

  1. Integrated mode only works for SharePoint Web Applications on the Default Zone
  2. Integrated mode will not work on a Web Application that has Anonymous access enabled

If you have a multiple SharePoint Server Farm:

  1. Install the SSRS SharePoint Add-in on the server hosting Central Admin first
  2. Instruction say that you only require a "Files Only" install of the add-in on the other WFE's but this is not enough.
    copyappbincontent stsadm command must also be executed on each WFE
  3. If using Kerberos and NLB, the DNS entry for the Web Application URL must be an A record, not CNAME
    Even if you have configured Kerberos on your MOSS farm, clients might still be authenticating using NTLM if this is not an A record
    (KerbTray and http://www.wssdemo.com/Blog/archive/2009/06/12/Testing-SharePoint-Kerberos-Configuration.aspx will help confirm/debug this)

I struck all of these problems across 2 customers in the last 2 days...
This is probably a session I should have submitted for the NZ Community SharePoint Conference 2009. Maybe I will change one of my TechED NZ sessions to this. Would anyone attending NZ TechED be interested in this?

Categories:

 
Jun
12

I found this nice asp.net application by to test end-to-end Kerberos functionality.
http://blogs.iis.net/brian-murphy-booth/archive/2007/03/09/delegconfig-delegation-configuration-reporting-tool.aspx

By installing this application in a virtual directory of the IIS site hosting my SharePoint Web Application, I was able to confirm the SSRS reports hosted on the WFE would support integrated security through to the Reporting Server (SSRS not installed on the WFE) and that SSRS could connect to SQL or Analysis Services data sources also using integrated security (more on the enterprise deployment of SSRS on multi-server MOSS Integrated reporting solution using Kerberos in a future post). This required a triple hop impersonation.

Output from my test farm:

Process Identity

Domain Account?

DOMAIN\svc-moss-app is a valid domain account.

Explanation

 

Only accounts that are in Active Directory (domain user or computer accounts) can participate in Kerberos. This is because it is the domain controller (a.k.a. Key Distribution Center) that grants Kerberos Tickets. Local accounts are not recognized by Active Directory and cannot obtain Kerberos credentials. SYSTEM, Network Service, and Local Service are considered domain accounts as long as the server is part of a domain, however, Local Service cannot obtain network credentials for communicating with back-end servers.

Has a valid SPN?

A usable ServicePrincipalName of HTTP/Intranet.DOMAIN.org.net is configured on the DOMAIN\svc-moss-app account.

Explanation

 

This SPN will allow HTTP (Hyper Text Transfer Protocol) clients to connect to this particular service using Kerberos when:

The target process is running as DOMAIN\svc-moss-app

...And...

The host name portion of the URL or connection string is intranet.

Existing SPN's for DOMAIN\svc-moss-app:

HTTP/Intranet.DOMAIN.org.net

HTTP/Intranet

HTTP/mosswfe.DOMAIN.org.net

HTTP/mosswfe

An SPN (Service Principal Name) is much like a UPN (Universal Principal Name). UPN's are unique names for identifying a domain user account whereas SPN's are unique names that usually identify a domain computer account. An example of a UPN would be "myAlias@america.microsoft.com" instead of the standard "AMERICA\myAlias". Domain computers are granted two ServicePrincipalNames of type "HOST" by default when they are joined to the domain. Domain users are not granted any ServicePrincipalNames because their unique identifying name is generally a UniveralPrincipalName.

Duplicate SPNs?

There are no duplicates SPN's.

Explanation

 

Because an SPN is essentially a "username" for a service, a given SPN cannot be set on more than one account (user or computer account) at a time. If the same SPN is set on more than one Active Directory account, Directory Services will frequently create a ticket based on the account that has the "duplicate SPN". This "duplicate" is then sent to the server/service but the service will fail to decrypt the ticket propertly since it was created based on a different account.

Trusted for Delegation?

Account DOMAIN\svc-moss-app is Trusted for Delegation with Kerberos Only when connecting to any service

Explanation

 

When selecting "Trust for delegation" or "Trust for delegation using Kerberos only" (Windows 2000 version of Kerberos) the trusted account will be able to pass credentials to any other server or workstation in the domain. For this reason it is much more secure to use "Constrained Delegation" in a Windows Server 2003 domain.

It is NOT necessary to trust this account for delegation unless it needs to PASS credentials onto another server. "Trust for delegation" does not effect whether or not a user can connect to IIS with Kerberos. It only effects whether the user's token can be passed on to another backend computer from the IIS server. DO NOT trust this computer or any other account for delegation when attempting to get Kerberos working unless a process running under that account will also be passing credentials.

By default when using "Integrated Windows Authentication" through IIS, the authenticated user is granted a "Network Token" that cannot be passed to any other computers. When using delegation, the Token then can be passed to other computers as long as the user successfully connected with Kerberos credentials. This can have security implications because trusting an account for delegation essentially means that the account is being granted authority to do some actions that normally only a domain controller would be able to do.

The dictionary definition for "delegation" is when one is appointed to act on behalf of another. So in Windows terms when an account is trusted for delegation that means that the account is trusted to act on behalf of an authenticated user.

Backend Server

Domain Account?

DOMAIN\svc-moss-sql is a valid domain account.

Explanation

 

Only accounts that are in Active Directory (domain user or computer accounts) can participate in Kerberos. This is because it is the domain controller (a.k.a. Key Distribution Center) that grants Kerberos Tickets. Local accounts are not recognized by Active Directory and cannot obtain Kerberos credentials. SYSTEM, Network Service, and Local Service are considered domain accounts as long as the server is part of a domain, however, Local Service cannot obtain network credentials for communicating with back-end servers.

Has a valid SPN?

A usable ServicePrincipalName of MSSQLSVC/SQL.DOMAIN.org.net:1433 is configured on the DOMAIN\svc-moss-sql account.

Explanation

 

This SPN will allow SQL (Structered Query Language) clients to connect to this particular service using Kerberos when:

The target process is running as DOMAIN\svc-moss-sql

...And...

The host name portion of the URL or connection string is sql.

Existing SPN's for DOMAIN\svc-moss-sql:

MSSQLSVC/SQL.DOMAIN.org.net:1433

MSSQLSVC/SQL:1433

An SPN (Service Principal Name) is much like a UPN (Universal Principal Name). UPN's are unique names for identifying a domain user account whereas SPN's are unique names that usually identify a domain computer account. An example of a UPN would be "myAlias@america.microsoft.com" instead of the standard "AMERICA\myAlias". Domain computers are granted two ServicePrincipalNames of type "HOST" by default when they are joined to the domain. Domain users are not granted any ServicePrincipalNames because their unique identifying name is generally a UniveralPrincipalName.

Duplicate SPNs?

There are no duplicates SPN's.

Explanation

 

Because an SPN is essentially a "username" for a service, a given SPN cannot be set on more than one account (user or computer account) at a time. If the same SPN is set on more than one Active Directory account, Directory Services will frequently create a ticket based on the account that has the "duplicate SPN". This "duplicate" is then sent to the server/service but the service will fail to decrypt the ticket propertly since it was created based on a different account.

Authenticated User

Domain Account?

DOMAIN\Administrator is a valid domain account.

Explanation

 

Only accounts that are in Active Directory (domain user or computer accounts) can participate in Kerberos. This is because it is the domain controller (a.k.a. Key Distribution Center) that grants Kerberos Tickets. Local accounts are not recognized by Active Directory and cannot obtain Kerberos credentials. SYSTEM, Network Service, and Local Service are considered domain accounts as long as the server is part of a domain, however, Local Service cannot obtain network credentials for communicating with back-end servers.

Authentication Method?

You have connected from your browser to IIS using Kerberos authentication.

Explanation

 

Although IE has successfully connected to IIS using Kerberos it is still necessary to ensure the rest of the items in this list are properly configured in order for delegation to work also.

View authorization header (this is for informational purposes only)

Overall Status

Will Delegation Succeed?

The current configuration is correct for Delegating credentials with Kerberos.

Explanation

 

All the necessary items for delegating Kerberos credentials are configured correctly.

 

Categories:

 
Jun
9

I wasted a few hours on this last week and another couple of hours trying to confirm exactly under which circumstances the problem happens.

The Search Core Results web part returns some standard xml elements in the results. I wanted to get the document library name for documents returned in the search results. To do this you can use the <url> and <sitename> values with the substring-after XSLT function to trim the site name off the absolute URL which then lets you use substring-before / to get the document library part of the url (ignoring any folders that may exist in the file path).

The thing with XSLT string functions is that they are case sensitive and although the full item <url> in the results retains the case of any characters used when creating site and library names, the <sitename> element sometimes converts the site url to all lower case.

On one of my servers, if the document is in a folder of a document library of a site collection that has capital letter in the site name, the site url is converted to all lowercase. For all other documents in the root folder of libraries, the site url retains the correct case. On another server, any documents in a site collection under a managed path that has an upper case letter in the url suffers this problem.

The only thing I haven't tested is a search center sub site in the same site collection as a sub site with uppercase characters in the site name.

This means that I had to convert both the <url> and <sitename> values to lower case first (now that sounds like standard programming best practice anyway).

Categories:

 
Jun
8

My thinking on this after a customer asked me to define SharePoint Information Architecture (IM on IM ;-).

SharePoint Governance

Most Microsoft solutions are governed by the standards and guidelines that are focused around operations and development. These have already been well defined by Microsoft and various people in the SharePoint community. A key component of the SharePoint platform is the ability to manage information which requires IM disciplines normally found in EDRMS or Data Warehouse (e.g. Master Data Management) practices. The IM pillar of a SharePoint governance strategy must be defined in order to design and maintain an effective enterprise SharePoint platform.

Information management

Information management responsibilities are often spread throughout an organization. Examples are:

  • Corporate Communications – Branding material
  • IT – Network file Shares
  • Applications – Database storage
  • Legal – Record retention/disposal
  • Web Master – Internet/Intranet content

(of these, the network shares are most out of control so best not have IT define the use of SharePoint ;-)

Figure 1: Three Pillars of SharePoint Governance

Microsoft is very good at providing documentation (timing aside) and certifications for the IT Pro and Development requirements for SharePoint but there is an equally if not higher importance to be placed on the business requirements of Information Management which is responsible for.

No substance here, that is reserved for the customer...

Categories:

 
Jun
7

I have never been one for regurgitating old or other people's presentations which means I create a lot of work for myself. These are the presentations I'm working on: 

NZ SharePoint Conference, July 2-3 (Building apps/smash-ups with Data View/Form web part)

USA TechReady, 9 July 27-31 (SharePoint 2010 Enterprise Taxonomy stuff)

NZ TechED, September 14-16 (2 sessions, TBA)

Not as impressive as Joel's list... but I also have consulting utilization targets to achieve at the same time.

Categories: