I recently helped put together a client & partner portal implementation with SharePoint that had a very interesting network and domain architecture that I figured was worth blogging about. Not only was it a unique architecture, but the business requirements that lead us to make those decisions were quite fun to work through as well. This post details the network and active directory domain architectures that were implemented to meet the needs of this client (will be referred to as Contoso, since I can never tell when it's appropriate to refer to clients directly J).

Key Business Requirements driving Network Architecture:

BR1:    Clients and/or partners shall access the portal from either inside their company's network OR from the internet.

BR2:     The clients and partners shall be able to manage their own users, who will have access to the portal from within their company, and what role within their company they fulfill.

BR3:    The user's role within the client or partner company will impact what the user can see and do within the portal.

BR4:    Contoso will not take on the routine maintenance of user accounts, neither user account creation nor password maintenance. This administration must be completed by the client or partner.

BR5:    Clients and Partners shall not be able to view or edit user accounts from other clients or partners within the portal or user stores.

ISA Server? Federated Services? Extranet Forest?

Deciding on what network architecture to choose for this implementation was a rather interesting process, because there are a lot of pros and cons to decide between. There wasn't a "silver bullet", you could say. For that reason, I am not going to proclaim a "best practice", since there are a lot of unique variables every company will have to weigh before making a network decision if they are in a similar circumstance. Rather, I'll just walk through our decision making process.

A few different solutions that were considered were ISA Server, Active Directory Federation Services, and an Extranet forest.

ISA Server

ISA Server was not implemented for two reasons. First being that they were very adamant against the use of software firewalls, and secondly, they already were heavily invested in Cisco hardware firewall solutions.

Active Directory Federation Services (ADFS)

ADFS was the first technology that came to mind when considering how to implement this architecture. The big reason ADFS was an option is because we did not want to manage user accounts in any way, shape, or form. ADFS helps solve this issue because the user logs into their domain, and is issued a token. That token is passed to any claims aware application (MOSS) within the federation, and thus they will not need a new user account even if they are in separate domains which are not connected with a trust. Pretty cool right? Take a look at this diagram showing the handshake it takes to authenticate to SharePoint, and you might have some doubts:

It turns out that it takes 11 handshakes to get that token issued and accepted by the SharePoint portal! Additionally, you'll notice on the diagram that each company in the federation will require a minimum of two Federation servers setup for this to even work. Anyone knows if you're working with clients, or even partners, getting them on board to buy into new hardware will take more than a smile. This was reason enough for us to pass up on ADFS, despite the significant gains it provides on the user management side of things (or the lack thereof, you could say). To make things even worse, to my knowledge with ADFS, a user would have to VPN into their company's network before they'd be able to access any of our resources. For us, this wasn't acceptable (BR1) because we need to support users coming I from the internet. Step 1 in the diagram above shows the user going into their network to get a token, before they can access resources in the other company.

Extranet Forest

Since Federated Services was ruled out because of its complexities and improbable client and partner adoption, an extranet forest is the next best option, because if we have to house users, we want them separated from our internal domains. An extranet forest features a forest inside the DMZ separated by a firewall from the internal forest and network, and obviously the internet. There is a one way trust between the extranet forest and the internal forest so the extranet servers can access internal resources like databases. Ports 389, 443, and 445 (445 only during trust creation) will be opened to allow for this traffic to flow between forests.

As I said, user account management was a big item that we didn't want to take on (BR2). It's possible to setup one way trusts between the extranet forest and the partner's forest. With that, the partners/clients will have access to the extranet forest's active directory to manage their own user accounts. This sounds great at first, but poses a big disadvantage for two reasons:

1. Partners/Clients will need to setup this AD trust – this could be a significant security hurdle if getting audited is a concern for the partner or client.
2. User account passwords and other meta-data won't be synchronized if it changes in the partners native domain.

This is the trade off. With ADFS, you won't need to worry about these two items because the user logs into their own domain, and is issued a token that is transferred to the Claims Aware SharePoint portal. However, we already decided against ADFS for various other reasons that outweighed these, but we still need a solution nevertheless. This is where ActiveRoles Server from Quest comes into play. Here's the description Quest gives for their product:

"ActiveRoles Server helps you manage, automatically provision, reprovision and, more importantly, deprovision users quickly, efficiently and securely in Active Directory, AD LDS (formerly ADAM) and beyond. ActiveRoles Server provides strictly enforced role-based security, automated group management, change approval and easy-to-use Web interfaces for self service to achieve practical user and group lifecycle management for the Windows enterprise."

With ActiveRoles Server, we will not require partners or clients to have a trust with our external forest. They can simply login to a web site to add/remove user accounts in the extranet forest's domain and we won't have to be responsible to identify and maintain who has access to what. Each partner is separated by having their own Organizational Unit (OU) so they can't see users from other partners or clients (fulfilling BR5). As far as password synchronization goes, we still don't have a solution for that, but with ActiveRoles Server, we are much better off than managing the users ourselves. That would be really expensive to support! What's also great about using this user management solution is now we only needed to open port 80/443 to the internet. If we needed to setup trusts, we would have to be more exposed. The diagram below shows a summary of the network architecture:

The diagram also shows the production servers spread across the two production domains (CONTOSO.EXT - extranet & CONTOSO.CORP – internal). Additionally, the two non-production domains, CONTOSO.TST and CONTOSO.DEV are shown inside the internal forest.

All in all, I think this was an interesting design for a client/partner portal solution. Clients and Partners have access to add/remove users as they see fit, and can place those users in predefined groups which will dictate their role within the portal. Plus those partners and clients can't see other partners or clients, because they're separated by OUs. Additionally, using the extranet forest with ActiveRoles server, keeps the overhead of user management off our plate, while at the same time keeping all these OUs and users our of our internal domains.

What do you think?

Phil