If an external user managed to "bust out" of the box, then he or she potentially has some level of access on your LAN. It could be argued that many practices like group usage, auditing, etc. will be used. It can also be argued that allowing a user a login on a single windows box (the SharePoint server, presumably) is safer than a locked down ADS account. But no matter how you do this, if a user COULD bust out or through (far more likely due to, or aided by, a mis-configuration than by pure hacking) and also have an account on your LAN, how well are you going to sleep? Another point is that a load balanced situation (one SQL server and two web servers perhaps) has the potential of forcing you back into ADS usage, because (for example) an embedded ASP.NET application might require an account that needs to (potentially) be on more than one server to work correctly. In the case of using SQL, both web servers can pull from the same SQL server. Yet back to ADS, one obvious answer here is put them on ADS, where more than one server uses the same central data source. But we are then back to the same concern. You could run multiple ADS structures but this has pitfalls, and is unlikely. And finally, a misnomer to debunk is the fact that once a user account is created, there are not too many things that are often done to these accounts. It may be possible you are making Exchange accounts for these users, but clearly that would be a need to an ADS usage. We are proposing a situation where many to thousands of users are needed, yet they are basically bare. And once the users are made, systems inside of SharePoint will be used to create and delete groups, will then be used to control access to objects such as webs, sub-webs, documents and lists.

Then comes the idea of creating and storing these accounts in SQL. And there are many reasons for this to be done, not the least of which is based on not only on price, but on security as well. Two examples of security include 1. The web interfaces that may be needed for users to create their own accounts never deal with ADS(I) components and 2. There is no correlation between users of SharePoint (stored in SQL) and users on the LAN, if security problems do come up.

So, of course, the primary question many people have is, how is this done? To be honest, it is not too tough, nor too easy. Microsoft has added some features that assist you in this process, but they have not done all of the work… trust me, at this point you do not just "throw a switch."

But, as a simple heads up of what is to come, you will use Forms Authentication along with SQL. Even with that knowledge, the details can be considered complex. This document will attempt to demystify this process.

Finally, before continuing, the reason that this document is labeled 1 of 2 is because, as I attempt to do in many of the articles, I will try to display for you a simple process of getting started, how it works, and why, then another article will come along to discuss more finely grained details. It may or may not be obvious what I am referring to by the end of this document, but in the beginning of the other documents it will become more obvious.