Category Archives: SharePoint

Siteminder Agent for SharePoint 2010 – extra notes

Archive, SharePoint, ,

This is more of a reminder for myself but if you ever get a dreaded Tomcat 500 message from the agent and SSL errors in the siteminder logs than the included openssl s_client command will be your friend.

In our case, the reverse proxy servlet was unable to retrieve the SharePoint pages due to certificate validation errors.  Everything on the SiteMinder server looked correct.  We assumed our SharePoint certificates were fine as we could reach the ClaimsWS, providing the certificate for client authentication successfully.

Finally after comparing a working environment against this broken one using the openssl s_client tool.  We found that the full certificate chain was not being sent to SiteMinder.  Turns out one of the intermediate certs was corrupted and showing as self signed instead of pointing back to the root CA cert.

A quick re-export of the intermediate certificate from a working environment and a rebind and we were back in business (after many hours burned on it).

openssl s_client -connect host:port -showcerts

Siteminder Agent for SharePoint 2010

Archive, SharePoint

A relatively new offering from CA is the SiteMinder Agent for SharePoint 2010.  I’ve had the “privilege” of working with this product and while I’m impressed with its integration and what it does, be warned, you will need some patience and to be well versed in working on multiple web platforms.

I say this because the installation and configuration is a mashup of vanilla Apache, TomCat, mutliple different SSL tools, some proprietary CA configurations (that are not yet well documented), and all of the usual SharePoint tools (IIS/PowerShell/Claims Based authentication).

From my own experience with SiteMinder, it is very much a Unix targeted product.  As such it is not surprising that it relies on Unix’s web server heavy hitters, Apache and tomcat.  Tomcat is capable of running as an independent web server, or can have traffic routed to it from another webserver such as Apache.  In the case of the Siteminder Agent, it is doing double duty as it uses both modes.

For this reason, if you are a SharePoint administrator seeking to implement the SiteMinder agent, its time to get very familiar with these technologies as well.  Important things to pay attention to if you are a straight IIS admin:

1) Configuration files are case sensitive.  If in doubt, copy and paste your paths.
2) Paths may either require forward slashes where backslashes are usually used in Windows, or they may need to be escaped backslashes.  This depends on which configuration file you’re editing so pay attention.
3) Get comfortable with a command prompt and Notepad (I highly suggest choosing powershell over the vanilla command prompt for authcomplete goodness)

We decided to implement SSL which doubled our complexity.  Additional skill needed here:

1) Familiarty with openssl command line tools.  These will handle your certificates for the Siteminder Apache httpd server
2) Familiarity with Java’s keytool.  This will handle your certificates for the Tomcat server.
3) Windows certificates, and SharePoint’s Trust store.
4) A good understanding of SSL/TLS, the handshake and client authentication for troubleshooting.

Quick note about #3, any SSL service that SharePoint is going to connect to, must have the destination’s SSL certificate (or it’s CA) added to the SharePoint trust store.  It does not use the Windows certificate store to trust remote servers.  But, you’ll still need to be comfortable with working with the Window’s certificate store in order to install and grant your IIS apps access to SSL certificates.  This is to identify your servers to remote machines.  Why they moved the trust store within SharePoint while still requiring knowledge of the Windows Certificate store for its own identification is beyond me.

Quick note about #4, out of the box, one of the services that comes with the Agent for SharePoint requires client SSL authentication.  That is, any server (WFE) attempting to connect to the agent must submit it’s own SSL certificate and the agent must trust and handshake with it.  You can turn this off on the agent side, but it is an added level of security to prevent unauthorized access to your directory of users.

At the end of the day, the CA SiteMinder Agent for SharePoint 2010 is not a small undertaking, so be sure you are familiar with the tools that will need to be used.

Webservice Calls with Windows Claims

Archive, SharePoint, , , ,

We ran into a unique issue recently where we had a need to separate out application pool accounts but still needed to share data across web applications.  The hurdle here is that both applications were protected with claims based authentication using both Windows Claims and a third party Claims provider.

The idea to get around this is to use webservice calls with an elevated account from one web application to pull data from the other.  I’m sure, as with most things SharePoint there are a million and one ways to do this but this is what we went with and we were under a time crunch.

Great, this should be simple, lets just make an HttpWebRequest from one application to the other passing the credentials of the elevated account.  Not so much.  Every time we ran this code, it would just hit a brick wall, if the site was not warmed up, it would just time out.  If the site was warmed up we would get an exception that the target closed the connection.

After some searching I came across these two articlse.

http://msdn.microsoft.com/en-us/library/gg597521.aspx#SPS_LearningClaims_3_Tip2

http://blogs.technet.com/b/speschka/archive/2010/06/04/using-the-client-object-model-with-a-claims-based-auth-site-in-sharepoint-2010.aspx

The webservice call was a REST call, so we could test this in the browser and in doing so I was able to recreate the timeout/closed connection error.  I did notice that once logged in I was able to hit the URL fine.  I fired up fiddler to see if I could figure out what was different and I found that the difference between the requests was the FedAuth cookie mentioned in the above articles.

So how to do this with a set of Windows creds and the Windows claim provider.  The articles only outline how to go over this with an ADFS claims provider.  Back into fiddler, I took a look at the request/response where I first received the auth cookie.  Why not add a request to this url passing in our creds and see what we get.

Success!  You’ll find the code below used to test this out.  The missing piece:

http://hostname/_windows/default.aspx?ReturnUrl=/_layouts/Authenticate.aspx?Source=%252F&Source=/

The code:

static void Main(string[] args)
        {
            #region getAuth
            Console.WriteLine("Enter user domain");
            string domain = Console.ReadLine();
            Console.WriteLine("Enter username");
            string username = Console.ReadLine();
            Console.WriteLine("Enter password");
            string password = Console.ReadLine();

            NetworkCredential nc = new NetworkCredential(username, password, domain);
            CredentialCache ccCreds = new CredentialCache();
            ccCreds.Add(new Uri("http://hostname/"), "NTLM", nc);
            string FedAuth = "";
            try
            {
                Console.WriteLine("Authenticating");
                HttpWebRequest authReq = 
                     HttpWebRequest.Create("http://hostname/_windows/default.aspx?ReturnUrl=/"+
                     "_layouts/Authenticate.aspx?Source=%252F&Source=/") as HttpWebRequest;
                authReq.Method = "GET";
                authReq.Accept = @"*/*";
                authReq.CookieContainer = new CookieContainer();
                authReq.AllowAutoRedirect = false;
                //authReq.UseDefaultCredentials = true;
                authReq.UseDefaultCredentials = false;
                authReq.Credentials = ccCreds;
                HttpWebResponse webResponse = authReq.GetResponse() as HttpWebResponse;
                FedAuth = webResponse.Cookies["FedAuth"].Value;
                webResponse.Close();
            }
            catch (System.Net.WebException e)
            {
                if (e.Response != null)
                {
                    HttpWebResponse webResponse = e.Response as HttpWebResponse;
                    if (webResponse.StatusCode == HttpStatusCode.InternalServerError)
                    {
                        if ((e.Response as HttpWebResponse).Cookies != null)
                        {
                            FedAuth = webResponse.Cookies["FedAuth"].Value;
                        }
                    }
                    webResponse.Close();
                }
            }
            #endregion

            HttpWebRequest hwrTester = (HttpWebRequest)HttpWebRequest.Create("http://host/_vti_bin/listdata.svc");

            if (!String.IsNullOrEmpty(FedAuth))
            {
                Console.WriteLine("Auth found!");
                try
                {
                    hwrTester.Method = "GET";
                    hwrTester.Accept = @"*/*";
                    hwrTester.Headers.Add("Accept-Encoding", "gzip, deflate");
                    hwrTester.KeepAlive = true;
                    CookieContainer cc = new CookieContainer();
                    Cookie authcookie = new Cookie("FedAuth", FedAuth);
                    authcookie.Expires = DateTime.Now.AddHours(1);
                    authcookie.Path = "/";
                    authcookie.Secure = true;
                    authcookie.HttpOnly = true;
                    authcookie.Domain = hwrTester.RequestUri.Host;
                    cc.Add(authcookie);

                    hwrTester.CookieContainer = cc;
                    hwrTester.UseDefaultCredentials = true;
                    //hwrTester.UseDefaultCredentials = false;
                    hwrTester.Credentials = ccCreds;
                    hwrTester.Headers.Add("X-FORMS_BASE_AUTH_ACCEPTED", "f");

                    HttpWebResponse hwrespResp = (HttpWebResponse)hwrTester.GetResponse();
                    StreamReader data = new StreamReader(hwrespResp.GetResponseStream(), true);
                    string output = data.ReadToEnd();
                    data.Close();
                    hwrespResp.Close();
                    Console.WriteLine("Got response from list webservice!");
                    Console.Write(output);
                }
                catch (System.Net.WebException e)
                {
                    if (e.Response != null)
                    {
                        e.Response.Close();
                    }
                }
            }
        }

Unghosted Content-Type Title overrides FieldRef DisplayName

Archive, SharePoint

New problem that cropped up today.  On a SharePoint 2010 site, the Base Title field was modified with the intention of making it not required on the contacts list.  Now this should have been done on the content type, or list level, but as is possible to do, the site column itself was modified.  (Note I’ll use FieldRef and SPFieldLink interchangeably in this post as I’m pretty sure the CAML schema and OM both refer to the same data)

Fallout:  the toot title column is now unghosted and what we’re seeing is that the Title attribute for the root column is now showing up for all inherited fields.  Even those with a different DisplayName in their FieldRef.  Most prominently is the Last Name column on Contact Lists.

We can modify the column on each list to display properly but as soon as a new list is created, its back to “Title”.

I dug in with powershell and the SPFieldLink still specifies that it should read “Last Name” in the DisplayName property.  If I look at the site collection content type it still lists the column as “Last Name”

The only thing I can think of is that the code that renders the List view is improperly just applying the un-ghosted column title if it finds one and ignores the other cases.  Whereas with a ghosted column, it will respect the FieldRef’s DisplayName.

I don’t have a solution yet, but I’m seeing if this occurs in MOSS as well.  Until then do not modify out of the box root site columns!

Edit: Confirmed similar behavior in MOSS/WSS 3.0

*Update
I ended up having to contact Microsoft premium support on this one, and given the nature of licensing, support models, etc I’m not sure if I can publish the fix. That said, they have a quick solution that involves some of the out of the box features so please, if you have this issue and a support contract with them, open a ticket.

2010 Calendars won’t print in IE7

Archive, SharePoint

So your SharePoint site is using the new v4 UI, everything looks slick and pretty.  But wait, you work in an environment where you have to support IE7 and your calendars won’t print properly.  Given the popularity of SharePoint, especially among all of the large companies and the public sector, it shouldn’t be surprising that not everyone can just upgrade IE just because the calendar is broken as suggested here:

http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/1d2555fe-f0aa-467b-8d2b-6732b5da52a4/

I find myself in that very situation and I’m hoping that I can offer a fix (or a start to one as its not the prettiest).  The end of the technet posting suggests that the issue lies with calendarv4.css found in the hive.  I decided to devote a few hours to digging in with the IE developer tools (both IE7 and IE9).

I assumed that this was probably one of the usual IE7 bugs with  haslayout and all the above so I started there.  I tried everything from zoom to height, to changing the display to no avail.  So lets assume that the calendar items are on the printout (but off the page).  A little absolute positioning some and I could get it to show up, but not on the calendar grid.  Slowly I tweaked it and saw the items disappear behind.  Maybe z-index, nope, maybe if I float it, nope.  Finally I decided to toss the style-sheet into the w3 validation tool.  Hey, there’s an error with overflow-x…overflow could cause the items to clip improperly and there are overflows all over calendar v4.  Why not mess with that.

Finally I was able to find something that would work.  I started out throwing the anvil at it

body *
{
overflow:visible !important;
}

Hey it worked, but I don’t want to have it affect anything outside the calendar. After a little more digging I settled on:

<style type="text/css">
@media Print
{
  .ms-acal-rootdiv * {
    *OVERFLOW: visible !important
  }
  .ms-acal-item {
    *OVERFLOW: hidden !important
  }
}
</style>

Toss that in however you prefer (content editor web part, additionalpagehead UserControl or what have you) and voila, you can print 2010 v4 calendars in IE7.

I pretty much stopped as soon as I had something that worked and was isolated to the calendar blocks, so this could be tuned more to find the actual style that breaks in IE7, but that’s more time than I want to devote to this.