SharePoint Claims Based Authentication Architectures Explained – Part 1 – Intro To Claims Architectures

You will find that the internet offers plenty applications that are interactive. This allows users to be able to access them simply by reading a hyperlink in text and then clicking on it. When this process is initiated, the information they seek more about will come up. The reader anticipates that the websites are going to monitor who is logged into them and for how long. No one wants to have to put in their password over and over again to be able to benefit from such a process though.

Instead they want to be able to enter it once and then to access any of those company based applications from it. It is very important for any such development that is created for the web to be able to support this need from the user’s point of view. It will be referred to here as a process called single sign on. You may hear it referred to out there though as passive federation.

Many people have had experienced with the world of Windows, and that is a single sign on concept that they use. Once you have logged in with your password the first time that day you will have access to all of the resources that are part of that hosted network. Windows is able to authenticate that password for each entity you wish to access. This is why you can avoid having to type it in again and again.

Kerberos is extremely popular but that has also resulted in it losing flexibility as a cross source. The domain controller is the one that has the keys to all of the resources that people within a given organization are able to access. There are firewalls in place that carefully guard such activities. When you aren’t at the office, you can access them through a VPN to the corporate network connection.

Kerbos isn’t very flexible when it comes to the information that is provided either. Many people would love to see it include arbitrary claims including email address access. However, that isn’t something that you are able to find at this point in time. With claims though you have such flexibility present. You are only limited in what you can access by two things your own imagination and the policies that your IT developers for the business have in place.

There are standard entities in place that allow you to cross different boundaries in terms of security. This includes both platforms and firewalls. They reason for this is that it makes it easier for it all to be able to communicate with the others. With this in mind, the application doesn’t have to verify the users.

Instead, the application needs to have a security token that is provided by the issuer trustee. When the IT department needs to increase security then the users have to use a smart card rather than a username and password for access. However, it won’t have to be reconfigured so that isn’t a time consuming process.

Even so, domain controllers will still be in place to offer security when it comes to the various resources of a given organization. There will be various issues for businesses to consider too. For example they will need to figure out how to resolve issues relating to trust. There are legal issues that have to be reviewed before entering into a contract with one is completed. You can be confident that claims based identity won’t change those needs that are already in place relating to such issues.

What will change though based on it is that there will be layers to the claims. Some of the barriers that are now in place will be removed. The result will be a single sign on solution that is also flexible for the needs of the users. Claims work is designed to be able to work within the security that already exists. It will eliminate many of the technical problems that are currently experienced.

Share

Caveats of Protecting Your SharePoint Environment with Microsoft Data Protection Manager

* This article was written in the context of System Center Data Protection Manager 2006 (SCDPM), a technology now considered deprecated with the introduction of System Center Data Protection Manager 2007. Variations may exist. *
 
Caveats of Protecting Your SharePoint Environment with Microsoft Data Protection Manager 
There are certain caveats that exist when using Microsoft Data Protection Manager within your SharePoint environment that have to be taken into consideration when planning your deployment and disaster recovery strategy. These caveats are very important when considering the impact that they might have on your enterprise environment and disaster recovery.
 
 
The Largest Caveat
The largest caveat that exists with a marriage of DPM and SharePoint is support for SQL backups (minus using the backup feature to export and flat file exportation) is not currently supported. This feature is planned to be built in the second half of 2007. 
 
 
Hardware Requirements for Microsoft Data Protection Manager
Firstly, you have to look at the actual server itself that you are using as your DPM environment. Running DPM requires using Windows Server 2003 with at the very least SP1 applied, and because you will require two volumes for DPM to function correctly you will need to have two different hardrives.  If you attempt to install DPM on a server with only one harddrive, you will get an exception thrown during the setup dialog. You can optionally add this volume at a later date. The reason that there are two harddrives required is the first will be the OS and relevant DPM program files, and the second will be used for data backups, and nothing else. Putting other program files on the second harddrive could possibly cause the DPM server to crash. Make sure that you also meet over the hardware requirements as well. Allocate at least:
  1. A 2 GHz or faster processor
  2. 2 GB of RAM
  3. 3 times the harddrive space as the estimated protected data
These are over the Microsoft recommendations, however when backing up SharePoint farms it can be a rather resource intensive process and therefore is better to plan over estimations that are more tailored to environments where DPM is mainly used as a file share backup mechanism. As well, SharePoint typically will increase the amount of data stored within its repositories dramatically from initial implementation to full production use by organizational virtual teams, and will only get larger as time progresses and more users adopt to using it. Multiplying your estimates by three is a guess, and the amount of disk space that you use should be on a company by company basis. 
 
Constantly Changing Data In Exported Backup Files
Remember that similar to SharePoint, Data Protection Manager will keep different revisions of its backups. Content housed within SharePoint is changed extremely frequently, since initial document creation can be housed there through an arbitrary amount of changes with an arbitrary amount parties involved. This can be from a single to a triple digit number depending on the nature of the documentation or object. One must plan accordingly with this in mind. Although DPM will only keep revision of the changes, it still can be a large amount when considering the environment we are tailoring DPM for is SharePoint. 
 
Ensuring Server Compliance Requirements for Data Protection Manager
Secondly, you have to look at the servers that you have available to assimilate into your DPM environment. Within a SharePoint environment, it is fairly atypical to have any other servers other than Windows Server 2003 running, however with some networks there are often other versions of servers such as Windows Server 2000. If you are using a Windows 2000 machine for your data storage, you should firstly install Service Pack 4. If you have other breeds of servers within your environment such as Unix and Linux, these servers are obviously not supported as data stored for DPM as well, as well, you can’t deploy agents to these servers since they won’t be compatible with the executables.
 
For Fresh Windows Server 2003 Installations 
Once you have Windows 2003 installed, it will bring up an .hta file which will allow you to configure server roles. Role implementation can also be launched by selecting the manage server roles selection out of the program files menu, or can be manually configured using the add/remove program dialog. You can configure the server with any role you choose besides a domain controller. Since the server will be querying other servers within the environment for disk-to-disk backups, it must be a member of the domain that your SharePoint server and SQL cluster reside on. It is not wise to put other software on this server as well, try to keep it as built down as possible so as not to interfere with other DPM processes.
 
Say No to Encryption with DPM
With SharePoint, the files that we are mostly concerned with protecting will be the exported SQL backup files and SharePoint file stores. There are some file types that are impossible for DPM to backup however, most notably those that are already encrypted, such as documents encrypted with PGP or other relevant encryption engines. When doing system restores of your SharePoint servers, there are other assets that will not stored within the backup, such as:
  • Paging Files
  • The Recycle Bin
  • Volume Information Folder
With SharePoint, there is typically not an end-to-end encryption solution in place because storing encrypted document within SharePoint repositories will confuse the gatherer and searching since it can’t correctly flag the data within the document. An end-to-end encryption solution for SharePoint that carries the encryption cipher is a piece of software currently being developed at ARB Security Solutions.
With the default package of DPM, there are the possibilities of using three different agents, for three different servers, purchasing more agents is relatively inexpensive if you need to protect more assets within your environment.
Share