Monday 19 March 2012

Sharepoint error "The security token username and password could not be validated" during claims based authentication configuration

There are many great tutorials on configuring Sharepoint 2010 (SP) to use claims based authentication such as this one by SharepointChick. Claims based authentication is a handy way to pair SP with a lightweight LDAP directory.

The configuration is reasonably complex and determining where an error lies is a balancing act between windows event viewer, LDAP logs and ULS logs.

One such error I received during my SP and OpenLDAP configuration was an event viewer application log.

Source: SharePoint Foundation
Event ID: 8306
Task: Claims Authentication
Error: An exception occured when trying to issue security token: The security token username and password could not be validated..

This error is accompanied with the inability to login to your SP site. A quick google search turned up a number of users in the same boat and plenty of suggestions but no definitive answers.




Clumsy Configuration

When you are working from configuration samples and writing large portions of text based configuration there is always the possibility of data entry errors.

Any of the tutorials you follow, such as this one, will ask you to create a new web application, select claims based authentication and then do some manual configuration in some of the web.config files on your SP site.

This is where the doubt creeps in, during the configuration of a membership provider, depending on the tutorial you are reading, you may be asked to configure a "ASP.net membership provider" with  "useDNAttribute" or "userDNAttribute" or both.

As soon as I removed "userDNAttribute" and set "useDNAttribute" to false, everything worked for me and the security token validation error message disappeared. I am not sure if this is because I am using OpenLDAP or if that makes any difference at all.

The below configuration is an example of my working membership provider syntax.
<membership>
<providers>
      <add name="LdapMember"
         type="Microsoft.Office.Server.Security.LdapMembershipProvider,
 Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral,
 PublicKeyToken=71e9bce111e9429c"
         server="192.168.1.1
         port="389"
         useSSL="false"
         useDNAttribute="false"
         userNameAttribute="cn"
         userContainer="ou=users,dc=contoso,dc=local"
         userObjectClass="inetOrgPerson"
         userFilter="(ObjectClass=inetOrgPerson)"
         scope="Subtree"
         connectionUsername="Cn=sharepointuser,dc=contoso,dc=local"
         connectionPassword="password"
         otherRequiredUserAttributes="title,sn,cn,mail,description"/>
   </providers>
</membership>

Looking back retrospectively it seems like an obvious and easy to fix problem, but when there are so many variables at play it isn't always so easy.

Sunday 11 March 2012

Sophos Enterprise Console 5 displays clients as "Awaiting policy transfer" after upgrade

I am yet to have a smooth Sophos Enterprise Console (EC) upgrade, there is always some certificate, configuration or downright weird issue. This time after upgrading from 4.7 to 5.0 everything seemed perfect, I should of known that was too good to be true.

After a policy change didn't find its want to my endpoint's I did some digging in EC and found nearly all of my endpoints were hanging at "Awaiting policy transfer". The only clients that were the "Same as policy" had been rebuilt since the EC upgrade took place.

Immediately I though of the dreaded Sophos certificate problem but further investigation ruled out this theory, fortunately the resolution was much easier.



Please update my policy changes!

1. Fire up EC 5

2. Right click any computer that is turned on but still "awaiting policy transfer", then select "View Computer Details"

3. Here you find the the status of all the policies on the selected client. For example "Anti-Virus and HIPS Policy", "Updating Policy" and "Application control policy".

Take note of all the policies that are "awaiting policy transfer", these are the ones we will need to fix.

4. The fix is ridiculously easy, edit one of the policies that are "awaiting policy transfer" and change one option. After changing the option, change it back to your original setting then press OK. Repeat for all policies hanging at "Awaiting policy transfer".

Huh? Hold on, I didn't change anything right? All I did was check an option then un-check it. Correct! But what I did do was trigger a policy update of old EC 4.7 policies. I am not sure if this changes some underlying configuration or perhaps updates an out of date check sum, regardless of what is happening behind the scenes it resolves my problem.

In the below image I opened my "Tamper Protection Policy" which was "awaiting policy transfer". I then checked "enabled tamper protection", then immediately unchecked it and clicked OK. Shortly after my clients begin receiving the updated policy.
 

Savour this fix, it's the easiest Sophos resolution you will ever get.

Thursday 1 March 2012

Querying the Sharepoint User Profile Service with Javascript and a content editor web part

So you've gone to the trouble of setting up the Sharepoint User Profile Service (UPS), mapping the attributes you want to use in Sharepoint and possibly troubleshooting some of UPS problems, what's next?

More than likely you want to start using some of these attributes and one of the easiest and most flexible ways to do this is with some Javascript and a content editor web part.



Some things you need to know

The content editor web part is a funny one, and acts differently depending on how you use it. Firstly you can paste Javascript directly into the content editor, but it is much easier to host your script in a .txt file and use the content link functionality to reference it. This gives you much more flexibility in editing, you can use your editor of your choice, instead of the flaky, awkward Sharepoint editor.

While waiting for the UPS XML query to complete there is a slight delay, therefore a simply Javascript document.write operation won't work for the response of the query. Instead we need to use Javascript ID tags in conjunction with syndication to insert the data dynamically into predefined areas of your script.

The actual request is a SOAP XML request, to which I need to credit this thread for the base code.



Enough rambling, how do I do it?

I am assuming you already have the User Profile Service configured and any attributes you want to import ready to go, configuration of UPS is outside the scope of this tutorial.

The below code gives an example of how I generated a Sharepoint entry page. My requirements were to pull a Student ID number from active directory that I could then use to generate URL's and pull data from external databases.

Click HERE for example code

In this simple example I am querying the UPS for a Student ID (stored in the Active Directory department attribute) and the users "Title" to create a welcome page for my Parent Portal.

Example dynamically generated content

Example dynamically generated link with "Student ID"


Most of the code is self explainatory but there are a few changes you will need to make to get started.

1. Please replace the sharepoint.contoso.local in the below line with the address of your Sharepoint UPS.
xmlHttpReq.open('POST', 'http://sharepoint.contoso.local/_vti_bin/UserProfileService.asmx', true);

2. I am pulling the Student ID, stored in the AD "department" field. If you change department in the below line, you can pull any attribute you want, providing you have configured the UPS to poll that attribute.
GetUserPropertyByAccountName(loginName, "department");
The returned value of this attribute will be set as "responsestuid" to which you can manipulate any way you like.


3.  At the top of the file I have multiple Javascript ID's, welcomeheader, linksheader, links. You can create as many IDs as you need and apply HTML to them such as font size and color. You can also place them in the other in which you want them to appear on the page.

For example because I want my "linksheader" above my "links", I position them as follows.
<font size = "4">
<script type="text/javascript" id="linksheader" src="syndication.js">
</script>
</font>

<font size = "2">
<script type="text/javascript" id="links" src="syndication.js">
</script>
</font>
4. Once you have made all the required changes to the example code, save it as "javascript.txt" and either upload it to a Sharepoint Library or any web server.
a. Create a new content editor web part.
b. Edit the web part.
c. Put the link to your "javascript.txt" in the "Content Link" box and press save.

With any luck you will being pulling attributes from UPS and creating dynamic pages based on those attributes!

If you are having troubles getting it working use an alert('error'), and move it further and further down the javascript.txt until it now longer appears when you load your page. This will give you a strong indication of where the error (normally a syntax error) might be in the code.