When it smells like security...

... it probably is security.

Ever since my first Classic ASP application, security on other peoples' servers has been a PITA. Deploying the app was one thing, but then getting read/write access to the data was another. Or getting access to a directory to upload images or other files required another round of interaction with the ISP to get the proper directories secured or not in the proper fashion. More modern Hosting interfaces have helped with this, but at the same time we've started doing more with hosted SQL server back ends and have encountered a new round of security related issues.

Most recently, security has been a stumbling block for us with a new client. As I've mentioned before, we've inherited a .NET application that has given us the opportunity for a crash course in many aspects of .NET development. This app uses web services for moving data back and forth and that has been interesting in and of itself.

It also uses ClickOnce deployment which we've never used before. Everything we read talks about how easy it is.

Last week we finished the modifications that the customer required in order to put this application into production. So, we agreed that on Friday we'd deploy to their server - or at least we'd try to.

We have the understanding that the web services require a basic copy-and-paste deployment. No problem there. The rest of the app, though needs to be published for ClickOnce Deployment.

So, according to all the "no instructions required" hits we got through Google and MSDN, we tried to publish to our customer's server. The first attempt failed with the following error:

Failed to connect to 'someURL' with the following
error: Unable to create the Web 'someURL'.
Internal Server Error 1 1 CSBS2.Client

Googling extensively yielded only one hit that was closely related to this and it was very specific to Vista (oh, and Security) After various attempts at changing things at our end, we were convinced it had to be something on the server. First of all, we were connected over a VPN using an assigned DOMAIN\username. The VPN connection was solid and we seemed to have rights to everything we needed. After making sure that our rights matched the previous developers' rights, we tried again with the exact same results.

I'm certainly no security expert but it seemed to me that we were missing a piece. We were logged into the development machine as OURDOMAIN\ourUserName and connected over the VPN using THEIRDOMAIN\TheirUserName. It seemed to me that when we published, we should be prompted for credentials on that domain and we never were.

So after more Googling on various parts of that error message, I finally found something on MSDN that matched the error exactly. It implied that FrontPage server extensions weren't installed. Aha! This looked promising. I looked and FrontPage server extensions were indeed installed, but this still seemed like something, so I kept looking around and discovered that there were FrontPage Server credentials for the previous developers, but not for us. Aha! I added the credentials, set the permissions, hit publish and whamo - I got prompted for credentials while trying to publish. Yahoo! I Typed in the credentials and immediately got the "Failed to connect to... " Darnit - no luck.

At that point, I was out of ideas. It still smelled like security. So I detailed all of this in an email Friday night. Today, I got email from the client that basically said "This rings a bell, I made a change in Active Directory. Try again." Guess what - it works now! Actually, we had to work through some issues with Certificates, but once we got past those, it was just as easy as everyone said it was.

For what it is worth - this security issue is probably one I never would have found on my own. As I mentioned, we are connecting over a VPN. When we need to touch SQL Server or test the application on their network, we use RDP. The customer had set us up to only have logon access to the machine we access via Terminal Server which is the SQL Server and the machine that hosts the click once deployment. This seems like a logical and secure thing to do. In order for us to be able to publish the ClickOnce deployment to that server, they had to give us rights to logon to All Computers in order for us to publish. They suggested that adding our computers to the logon list might have fixed this, but we haven't experimented.

Bottom line - if it smells like security, it probably is security. It's just up to you to figure out where that security is.