Fixing Access Denied Errors With SharePoint 2010 Timer Jobs

It is important to realize before we get started that this error was also present within SharePoint 2007. When creating timer jobs, it is important to understand the relationships between the SPSecurity.RunWithElevatedPrivileges method and the associated SPWebApplication object. When using SPSecurity.RunWithElevatedPrivileges, it will not allow modification of the SPWebApplication since it is persisted to the configuration database. However, other proxy objects are exempt from this such as SPSite ‘s and SPWeb ‘s. SPSecurity.RunWithElevatedPrivileges allows the elevation to just the content database, NOT the configuration database (which has the SPWebApplication property bag) which is generally more locked down.

The easiest way to fix this is to impersonate the user account for proxy objects (assuming you are using a current context to reference the application property) with an account that has the wss_content_application_pools database role for the config database since this will have elevated rights for stored procedures and what not. This will allow you to modify your timer jobs easily. If you want to be really lazy, just use the same account as the central admin app pool which inherently provides the required access to the configuration database.

Share

TFS Proxy Server Unexpected Shutdowns

TFS Proxy Servers are essential for my current client’s TFSenvironment because they allow the disparate SharePoint development environment to experience improved network performance by caching copies of VC files. Since this particular environment is geo-distributed, this is a necessary architectural requirement in order to maintain appropriate developer efficiency.

Recently, a strange issue was occurring with my clients geo-environment where the proxy servers would start shutting down repetitively. The exact error you may run into is:

The VSTF Proxy Server stopped at [server]. The application is being shutdown for the following reason: HostingEnvironment. For more information …..”

Now this can happen for a variety of reasons, but first thing is you should enable proxy server tracing to get some more relevant error information by opening the web.config in the VersionControlProxy folder by setting the traceDirectoryName to a familiar storage location and changing traceWriter to true. For this particular error, one of the error returns can be:

Detailed Message: TF53002: Unable to obtain registration data for application VersionControl.
TF30055: Visual Studio could not find or read the Team Foundation Server server name in the configuration file. Contact your Team Foundation Server administrator. (type VstfNotConfiguredException)

If you get this error, the TfsNameUrl appsetting is not configured in the web.config file for the proxy server. Locate the:
[xml]

[/xml]

element and change it. After, check your IIS app pool setting and check that the recycle interval or memory limit. After, you should be good to go!

Share

SharePoint Claims Based Authentication Architectures Explained Part 5 SharePoint Identity Across Realms

We have already talked about claims based identity and how to design a claims based application where the issuer is able to authenticate the users directly. You can actually take all of this one step further though. The process allows you to expand the capabilities of your issuer to accept a security token from another issuer. This means the user won’t have to directly authenticate it. Now the issuer is able to issue security tokens and to accept them from other issuers that it trusts.

As a result you will be able to have identity with other realms in spite of the fact that they are separate domains of security. This is a powerful ability that offers plenty of benefits. The process is accomplished by using the IT staff. They get to determine how issuers are going to be configured. You do need to understand these possibilities because they are the entry way to even more features for your application. You won’t have to change your application in any way though. Some of the different possibilities can offer some flexibility for your application design too.

Being able to maintain an identity database doesn’t have to be a difficult task. You can have a simple database that keeps the usernames and passwords that you need to manage in place. However, it is common for users to forget such information frequently. Chances are you have a high level of security in place for your business. Therefore it isn’t acceptable for you to just email those individuals new passwords.

It is very difficult to successfully manage a database for remote users. Lets say that you work for a partner company with a purchasing application. An IT staff make changes to your account as you work in the purchasing department. The IT staff gives you the role of purchaser so you are given permission to use the application. How are people with a different company going to learn about you being transferred to the sales department? What happens if you decide to quit your job for the company?

The changes will need to be found out, but don’t count on the human resources department to send out any type of notification. It should be something that the company you were employed with would need to manage. Storing information for remote users is often looked upon as a liability so keep that in mind. Any data that you store about remote users could turn out to be a liability for your business.

Over the course of time the data stored with a remote user will become old. There are some safe ways that you can expose applications so that a partner business will be able to use them. One of these methods involves decentralizing the process. You won’t have an issuer that authenticates remote users directly. Instead you will set up a trust relationship with an issuer that is part of another company.

Your issuer trusts their issuer to authenticate the users that are in the realm. These employees are satisfied because they don’t need any type of special credentials in order to be able to use your application. They will use the same single sign on ability that they used in their own company. Your application will work for them due to the came pass to get in. The claims you have to get the boarding pass for the remote users will be less powerful though because they aren’t really employees of your company.

It will be the responsibility of your issuer to determine those assignments. Your application won’t need to change either when new organizations are added as partners. This is a huge benefit of using claims because it allows your configuration of only one issuer to be accessed by so many new users out there.

It is possible to use claims to decentralize identity. This is going to eliminate data from becoming stale for remote users. Another benefit is that the claims will allow you to logically be able to store data about your users. The data can be stored with authority and be convenient to access and to use. Through the use of federation, many of the road blocks out there are removed so that new users can come in.

Your company will need to decide which realms to allow access to your claims based application. Your IT staff will be able to set up the relationships that need to be in place for them. They can get employees in a business that use Java to access your application but they won’t need to issue new passwords. They will only need to have a Java based issuer. Also, anyone with a Windows Live ID would be able to use your application.

Share