Blog - Robert Bogue [MVP]
Rob's Notebook
SharePoint Calendar
Thor Projects LLC - Welcome
Saturday, June 30, 2007

Domain Certificate Authority Signing InfoPath 2007 Forms

InfoPath forms with custom code and those that have their Security Level set to Full Trust must be signed so that they can be run by the client.  That’s fine but who wants to pay for a code signing certificate for internally developed applications?  If we string together a couple of facts we can quickly realize that we shouldn’t have to pay for code signing certificate if we are developing code that will only ever be used by internal users.

First, certificates work because there are a set of trusted root certificate authorities.  Their responsibility is to issue certificates.  The organizations running the trusted root certificate authorities are responsible for only issuing certificates where the certificate matches the organization requesting the certificate.  They make no judgment about whether the person is good or bad – only that they are who they say they are.  The service that you pay for when you purchase a certificate from a trusted root certificate authority is that they have verified your identity.

Microsoft Windows has a list of trusted root certificate authorities – but when a computer is in a domain, it automatically trusts the Enterprise Certificate Authority for the domain.  The Enterprise certificate authority is an instance of certificate services which comes with Windows Server operating systems.  It allows an administrator to issue certificates.  There are several templates for the kinds of certificates to be issued.  The most common one is for a web server – an SSL certificate – but there are others as well.

Certificate Services has a template for code signing certificates.  If you put everything together you realize that when all of your computers are a member of a domain you can request and get granted a code signing certificate that’s valid for anyone using the certificate in the domain.

Here’s how to do it…

Install Certificate Services

If you don’t have an Enterprise Certificate Authority in your domain, go to a server and …

1)      Click Start- Control Panel-Add/Remove Programs

2)      Click Windows Components

3)      Click the checkmark to the left of Certificate Services

4)      Click Next

5)      Follow the wizard to create an Enterprise Certificate Authority.

Note: There are special precautions for protecting enterprise certificate authorities including creating sub-authorities, and taking the certificate authority offline.  If your organization is large, you should review the risks and guidelines for creating certificate authorities and manage security appropriately.  In smaller organizations it’s generally acceptable to create an enterprise CA and issue certificates from it.

Create a Copy of the Code Signing Template

The default out of box code signing certificate doesn’t allow the certificate’s private key to be exported.  This means that only the user to which the certificate is issued can use it.  Generally you don’t want to have developers to have enough permission to request the certificate themselves.  If you want to be able to move the certificate from user to another you’ll need to make a copy of the Code Signing certificate and change it so it can have exportable keys.  We’re going to show you how to do this.  If you follow these steps choose your duplicated code signing certificate in the following steps.

1)      Click Start-Run and enter certtmpl.msc.

2)      Right click the Code Signing template and select Duplicate.

3)      Enter a name for the new Template.  For instance, add your organization name in front.

4)      Click the Request Handling tab.

5)      Click the Allow private key to be exported.

6)      Click OK.

You now have your own code signing template that can be exported.

Enable the Code Signing Template

By default the  code signing certificate template isn’t available to be issued from your certificate authority.  To do that you need to enable the template which you can do by following these steps…

1)      Click Start-Administrative Tools-Certification Authority

2)      Expand the server that you installed certificate services on

3)      Click the Certificate Templates folder.

4)      Right click the Certificate Templates folder, select New, Certificate Template to Issue.

5)      Click Code Signing and click the OK button.

Now you can issue Code Signing Certificates

Issue the Certificate

Now that everything is in place you can issue the certificate.  Follow these steps to do that…

1)      Open a web browser and navigate to http://server/certsrv where server is the name of the server which you installed certificate services.

2)      Click the Request a certificate link

3)      Click the advanced certificate request link

4)      Click the Create and submit a request to this CA link

5)      In the certificate template drop down box select Code Signing.

6)      Enter a friendly name for the certificate in the friendly name textbox at the end of the page.

7)      Click Submit.  You may be prompted that the web site is requesting a certificate, click Yes.

8)      Click the Install Certificate link. Again you may be warned that you’re getting a certificate, click Yes.

You now have a certificate in your certificates store.  If you’ve not been doing this as the developer (and you probably haven’t), you’ll need to export the certificate and import it into the developer’s account.  You’ll only be able to do this if you created your own code signing template.

Exporting the Certificate

Here’s what you need to do to export the certificate:

1)      Click Start-Run enter certmgr.msc

2)      Expand the Personal Folder

3)      Expand the Certificates folder

4)      Locate the certificate that indicates that its intended purposes is Code Signing.

5)      Right click on that item and select All Tasks-Export

6)      Click Next

7)      Click Yes, export the private key.

8)      Click Next.

9)      Click Next

10)   Enter a password and confirm password.

11)   Click Next

12)   Enter a file name for the exported file

13)   Click Next

14)   Click Finish

You’ve exported the certificate.

Importing the Certificate

If you’ve exported the certificate you can move that over to the user or machine that will be signing the code and follow these steps to import the certificate.

1)      Double click the file to start the Certificate Import Wizard.

2)      Click Next

3)      Click Next

4)      Enter the password you entered when you exported the file.

5)      Click Mark the key as exportable.

6)      Click Next

7)      Click Next

8)      Click Finish

9)      Click OK.

You’ve now imported the certificate file.

Configure InfoPath to Use the Certificate

The final step in this journey is to tell InfoPath to use the certificate.  Do that by following these steps…

1)      Open an InfoPath form in design view.

2)      Click Tools-Form Options

3)      In the category pane, click Security and Trust

4)      Click Sign this form template

5)      Click the Select Certificate button

6)      Select the certificate that you just issued.

7)      Click OK.

8)      Click OK.

OK, you’re done.  That’s all you need to do in order to get a code signing certificate that will sign InfoPath forms that the users of the organization will recognize.


Categories: Professional | 6 Comments
 
Tuesday, June 26, 2007

InfoPath 2007 Publishing to SharePoint: Updating the site content type failed

I’ve been struggling for a few days with issues related to InfoPath 2007 publishing to SharePoint.  I thought that I had tried everything.  I had tried publishing to a document library, as a content type, trying to modify content types, etc.  I got a variety of error messages including “Updating the site content type failed”.  This one was my favorite because there wasn’t anything in the content type that I asked InfoPath to update.

I realized later that it was updating the document template but I wasn’t thinking about that when I saw the error message.

What I realized when I dug into the issue is that InfoPath 2007 couldn’t modify the content type because it had been created at the site collection level – not the subsite level that I was doing my testing from.  You can only modify a content type from where it was created.  When I backed up in the wizard and I gave it the URL for the site collection root rather than the sub-site and then rolled forward through the wizard again it worked.

So if you’re having trouble getting InfoPath 2007 to publish to SharePoint … try publishing to the root of the site collection. (I still have other issues this didn’t fix like the fact that a properly derived form isn’t showing up as one to modify – but one problem down.)


Categories: Professional | 0 Comments
 
Sunday, June 24, 2007

Hints for Membership Providers (Authentication Providers) with SharePoint

I’ve done work with membership providers more than a few times now and I have developed a love-hate relationship with them within the context of SharePoint.  It’s not that membership providers don’t work.  They do.  You can absolutely make them work.  However, it’s also true that there are a lot of landmines in the way.  I wanted to provide a few of my experiences with Membership providers that may be helpful for you…

1)      Don’t start with SharePoint – If you’re going to work with Membership Providers in SharePoint – don’t start there.  Build a simple ASP.NET application that has a secure home page.  Make a login page.  Test your membership provider and its configuration settings in ASP.NET first.  Why?  There are less moving parts.  You can run an ASP.NET web site in debug mode by pressing F5.  You don’t have to deal with all of the other things that are going on inside SharePoint.  The fact that first chance exceptions work in ASP.NET (they don’t in SharePoint) you can try to capture the exceptions as they happen.  (If you don’t know about First Chance Exceptions you can go here.)

2)      Build a Shell – Even if you’ve tested the membership provider in ASP.NET there are reasons why SharePoint is different.  Instead of running with the local account you’re running within the context of the application pool.  Because of this you need to be able to see what’s happening between SharePoint and the Membership Provider.  You may need to see all of the call parameters and the return values – and even the exceptions.  So build yourself a passthrough provider which will log the calls, the responses, and the exceptions.  It will make figuring out what’s happening much easier.  (I have a version.  If you want a copy send me an email and I’ll send you a copy of it.  Better yet, if you’re willing to help review it and get it up on CodePlex let me know.)

3)      People Picker is Evil – The people picker is evil.  You’re supposed to be able to specify the provider to use when selecting a user (myProvider:TheUser).  Sometimes that actually works.  It works if you’re in the zone where the provider is the default, but doesn’t always work outside of that.  Add to the problems with the People Picker that you need to remember to add the search wildcard to the entry in the web.config.  So if you are getting stuck adding permissions… start with adding a Policy for the Web application (see Steve Peschka’s post on the SharePoint Products and Technologies team blog titled “Configuring Multiple Authentication Providers for SharePoint 2007”)

4)      Don’t ask everything of the membership provider – One of my clients wanted to login via email address in active directory – and not their UniquePrincipalName.  Although this is technically possible by using the LDAP provider, that may not be the best answer.  It may make more sense to modify the login page rather than trying to get the membership provider to log in on a field other than the ones that it’s used to logging in with.  In fact, on a scale of difficulty modifying the login page is must easier than mucking with membership providers.  I’ve got a forthcoming article on how to create a custom login page for SharePoint. I’ll add a link here when the article goes live.

 

Good luck on your work with membership providers…


Categories: Professional | 0 Comments
 
Sunday, June 24, 2007

System.DirectoryServices.Protocols (a.k.a. LDAP is your friend)

I’ve had the displeasure of trying to do some work with LDAP in .NET lately.  The interfaces are all there but the documentation and error handling isn’t.  (Read: The lights are on but no one is home.)  Because of this I was pleased to find there was a book out on the subject The .NET Developers Guide to Directory Services by Joe Kaplan and Ryan Dunn.

I also had the pleasure of sharing an email conversation with Joe.  I initiated a conversation with him slightly before I was able to pickup the book – because of his activity in the newsgroups.  I quickly figured out I needed to pick up the book and did.  I highly recommend it because the information that is contained in it is both unique -- because it doesn't exist elsewhere -- and is easy to understand.  LDAP may be common but it's not something that most developers do every day.  Back to my point, there were some interesting things that came out of that conversation.  I wanted to highlight them in part to document them and in part to thank Joe for his help.

1) System.DirectoryServices vs. System.DirectoryServices.Protocols – What I was trying to do was to develop a high performance LDAP ASP.NET 2.0 Membership Provider for a project.  In order to do that, I was going to be using LDAP to authenticate a large number of users.  One of the issues with System.DirectoryServices is cleaning up all of the connections quick enough in a high load environment.  The net of the conversation with Joe – which I agreed with wholeheartedly as I began to understand the underlying characteristics of System.DirectoryServices – was if you need to control cleanup of connections use System.DirectoryServices.Protocols.  The end I came to was that I think of System.DirectoryServices as a façade over System.DirectoryServices.Protocols.  Façade is a pattern that makes using something easier.

2) SSL is not your friend – There are lots of things to think about when trying to use SSL to encrypt your LDAP communications.  First, if you are using clients all in a domain, add an Enterprise Certification Authority to the domain.  If you do that the domain controllers will enroll themselves and start accepting SSL connections for LDAP – that’s cool.  If you don’t have all internal clients, you can refer to this KB article to add a third party certificate.  Even with it working (and tested via LDP) you may have a problem when you try to set SecureSocketLayer support.  You may receive a less than helpful DirectoryOperationException(“The server cannot handle directory requests.”) what isn’t quite so amusing about this is that it didn’t even try to communicate with the server.  The solution was to add the port number to the server.  So instead of passing “Server” to open the LdapConnection, I passed “server:636”.  By the way, LDAPS is port 636 – rather than the 389 port used by LDAP.

3) Fast Concurrent Bind isn’t really a bind – In LDAP you bind to associate credentials to your connection so that it can use those credentials to validate your operations.  One of the things that S.DS.P supports is the idea of a Fast Concurrent Bind.  Basically, check my credentials to make sure that they’re OK – and don’t do anything else.  I tried using Fast Concurrent Bind (because it is the fastest way to validate a user) to bind to a connection and then do a search.  So I did my bind and then did my search.  When I tried the search I got an exception – DirectoryOperationException(“An operation error occurred”) when I dug into the network capture I found a deeper message: “LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece”  It was funny because message 5 was a bind with a success response and message ID 6 – the one I got the error on was a search.  The issue at the end of the day I was I was using fast concurrent bind.  So I wasn’t really doing a full bind at all.  I was just authenticating the user.

With Joe’s help I was able to figure out what the issues were … and create a working solution.


Categories: Professional | 0 Comments
 
Tuesday, June 12, 2007

Bad Error – Missing User Controls in a Master Page in SharePoint

I had a customer come to me with a problem that they were getting a “File Not Found.” error while trying to move a site collection backup from one system to another.  The client is supposed to deliver their customizations via solutions files.  So I turned off custom errors, turned on the call stack and got this:

Server Error in '/' Application.

The resource cannot be found.

Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable.  Please review the following URL and make sure that it is spelled correctly.

Of course, that isn’t much help.  After some fun digging with SharePoint Spy and with SharePoint Designer, I discovered that the user control which was referenced in the custom master page (MasterUrl) didn’t exist in the directory it was being referenced from.  It turns out they had delivered the user controls outside of solutions packages to the integration environment.  The master file referenced them from the root of the ControlTemplates directory.  When they were packaged up they got deployed to a subdirectory of ControlTemplates – like they’re supposed to.   The problem is on a new server the controls weren’t in the root which caused the master page not to load which wasn’t well handled by SharePoint.  (Frankly, not that it should have been but an error in one of the logs would have been nice.)

Correct the master page location for the user controls and the problem goes away.


Categories: Professional | 0 Comments
 
Friday, June 01, 2007

SharePoint and Office Pro Plus

Most of the time, I don’t pay much attention to which specific package of Office that I’m using. I’m not talking version.  I’ve been running Office 2007 for more than a little bit now.  I’m not talking about that.  What I’m talking about is which edition I’m using.  Let me explain.

Microsoft sells the office bundle in Basic, Home & Student, Standard, Small Business, Professional, Professional Plus, Ultimate, and Enterprise versions.  There’s a good grid showing which programs you get with each version on the Microsoft Office Online site at http://office.microsoft.com/en-us/suites/FX101635841033.aspx

However, what’s not clear is that you can’t always assume that what you see is what you get – when you want to integrate with SharePoint.  You see there’s “magic” in Professional Plus, Enterprise, and Ultimate.  That “magic” does SharePoint integration “stuff”.  Some of it’s obvious.  Without InfoPath the document information panel (which is really an infoPath form) doesn’t work.

However, one of the issues that I ran into was that there’s some property copying stuff that’s supposed to work to enable SharePoint server based properties to be visible in the Office documents – in my case word.   I had installed Office Professional in my test environment and added InfoPath later.  As a result my Document Information Panel worked – but the properties weren’t getting copied back to the document – only when they were in a content type.

I uninstalled Office Pro and Infopath and resinstalled Office Ultimate to test and the problem went away.

This isn’t conclusive proof that the issue I was facing was due to trying to use Office Professional plus an installation of InfoPath to work with the server, but it’s a strong indication that there’s something missing when this is done.  So from now on if I need Office and SharePoint to have the best friendship … I’m going to be using Professional Plus or better … something that ships with InfoPath in the box.

No more Office Professional and SharePoint for me…  Now if I could just figure out how to get that time back…


Categories: Professional | 0 Comments