"External access" can be a confusing term. Are you talking about people who aren't physically on site? Are you talking about non-employees? To clarify, I started referring to a project as "non-employee identification and authorization." After banging out that phrase a few times, I realized that I had a ready acronym: NEIDA.
To me, adding NEIDA to the mix is where you really get the value out of Sharepoint (used generically - SPS is an application that rides on top of WSS). Sharepoint is a definite improvement over the cumbersome and kludgey ways we now share data internally, but those ways simply don't work at all with non-employees and remote personnel. For instance, if you want to grant a contractor access to a DFS share, you are forced to add this non-employee to your corporate directory, have him install a VPN client, and then let him run remote desktop. All of this assumes that you happen to have a spare workstation, either physical or virtual, for him to remote into. Very ugly. You are attempting to electronically convert the remote contractor into a physically co-located employee. This is silly and risky. Identity and location must be decoupled.
We've recognized and articulated the need for this capability for about two years now. But in our company (and I suspect in most large corporations), a single business unit with a huge project gets a lot more attention than a thousand voices spread throughout the enterprise. We now have that giant business unit stick, and are moving forward rapidly lest the stick is used to hit us.
Here's what we are doing specifically: We are putting a Microsoft ISA cluster in our DMZ and using it to securely publish Sharepoint, which is located on the corporate network. The ISA and Sharepoint boxes will belong to our separate extranet forest, which has a one-way trust with our corporate forest. Non-employees needing access will be given accounts in the extranet forest, and site administrators will grant those accounts access to specific containers within the extranet forest.
The nice bonus in this approach is that we solve the remote employee problem while addressing the non-employee problem. The more applications we publish, the less our need for remote desktop.
I'd be interested in hearing from anyone who's done anything similar. What gotchas, landmines, etc. await us?