We have a potential client that wants us to host a SharePoint site at a co-location. They have AD at their home office. They want SSO for this SP site and to be able to manage password resets and other account stuff themselves. I'm just learning about both ADFS and FIM.
My initial idea was to setup a new domain and ADFS at the colo site, then a FIM server as well, and integrate FIM with ADFS. Is that possible?
OR can we put a domain controller up at the colo site and join it to -their- domain via VPN tunnel, then set up just a FIM server and they have SSO and account control that way?
Any help is greatly appreciated..
Todas as Respostas
FIM and ADFS are not exactly related, although they can certainly be complementary... use FIM for provisioning, data synchronization, workflows, self-service data management and password reset; use ADFS for federated sign-in.
Steve Kradel, Zetetic LLC
I was also thinking I need this for my scenario..
UAG delivers comprehensive, secure remote access to corporate resources for
employees, partners, and vendors on both managed and unmanaged PCs and mobile
devices. It utilizes a combination of connectivity options, ranging from SSL VPN
to Direct Access, as well as built in configurations and policies, Forefront UAG
provides centralized and easy management of your organizations complete anywhere
Keep in mind that you need a trust between your external Active Directory and the AD with the FIM Server or you need shadow accounts for your external AD users in the FIM Forest to let the external logon to the FIM Portal for Password reset and self Service.
These are the requirements as I undestand them.
- Provide a secure infrastructure solution that can be accessed by users over the Internet.
- Provide an application portal to host applications for access by both internal and external users.
- Allow external users to create accounts.
- Allow external users to change their passwords.
- Provide external users with self-service password reset functionality.
- Allow internal users to leverage their current existing credentials for gaining access to the resources in this solution.
- Federated access to published applications by partner users.
- The solution must be secure, implemented in the DMZ environment, and ideally without Windows trusts between this solution environment and internal AD.
I don’t really know enough to know if it’s overly complex. This leverages several technolgies. ADFS, FIM and UAG.
What is UAG? You can read the snipit here about UAG.
Without any training or real world experience it’s really hard for me to speak authoritatively in such a small amount of time. There are also unanswered questions, like where the users are stored now and will they continue to be stored there.
FIM has to be involved because that allows for the simplified user management, but if they place their own domain controller in the remote environment, ADFS and UAG could possibly be skipped.
With this complex model you need the following
UAG server X 2 – UAG delivers comprehensive, secure remote access to corporate resources for employees, partners, and vendors on both managed and unmanaged PCs and mobile devices. It utilizes a combination of connectivity options, ranging from SSL VPN to Direct Access, as well as built in configurations and policies, Forefront UAG provides centralized and easy management of your organizations complete anywhere access offering.
UAG Trunk Design in this solution will have at least three trunks on each UAG server.
- The first trunk will publish Anonymous applications. This trunk will be configured without any authentication requirements. The following are primary applications that will be published via this trunk: Initial landing page for users with menu selection of different tasks
Self Service Password Reset application
Self-User Registration application
- The second trunk will publish a portal for external users with password change function
This trunk will use AD for primary authentication to the portal
Will use AD FS as secondary for claims-enabled apps
- The third trunk will publish a portal for users authenticating via SAML (Federated)
This trunk will use AD FS as the primary authentication to the portal
It will be configured as a relaying party with RP-STS
ADFS Server X2 – Federated authentication between AD forests. This accomplishes SSO between domains. One is located at the corporate site, one at the colocation site.
FIM portal Server - Forefront Identity Manager (FIM) provides self-service identity management for your users. FIM provide role-based access control and allow administrators to review access rights continually across the organization. The FIM 2010 R2 release also adds an improved self-service password reset experience, along with performance, diagnostic, and reporting improvements.
Active Directory Server X2 – Segregated authentication database collocated that communicates via ADFS to provide federated authentication while keeping user accounts separate from the corporate domain.
SharePoint 2013 WFE Server – SharePoint web front end tier
SharePoint 2013 Application Server – SharePoint application tier
Microsoft SQL Server – DB services for Sharepoint and FIM
Dual zone DNS for UAG – UAG DNS need to match both internally and externally
Colocated corporate AD
In this option a replica of the coporate AD is colocated. All accounts are kept in the corporate AD. ADFS is not needed. FIM and UAG services are required.
Does anyone know how UAG fits in to all of this?
My general preference would be to skip UAG entirely, as its main purpose is "outside-in" app publishing with device policy enforcement, and one can skip "outside-in" here by hosting Sharepoint and other apps available to third parties in a totally fenced-off environment relying on ADFS.
As henryschl points out, one instance of FIM cannot serve two forests without a trust between them... so one might prefer two separate instances of FIM, or possibly to use something other than FIM--such as a very good ASP.NET MembershipProvider, or custom apps--to support the external users. Also note that the FIM Portal is only supported for intranet scenarios; it's not a good fit for user self-service other than SSPR.
IMHO you might want to consider engaging an experienced consultant to help, as tackling FIM, ADFS, SPS, and AD:DS design and deployment all together is a really tall order when still brand new to FIM and ADFS. The learning curves on all of these are rather long; it is much more involved than deciding what technologies to use and where to host them.
Steve Kradel, Zetetic LLC
Well thanks, it looks like i got the right response. We want to keep it as simple as possible. We even thought of propping up another DC for their domain and having it communicate via vpn tunnel. That would only leave us needing the FIM portion.
Among the requirements from this customer, there must be the following.
Role based security
Internal and external access to the SP site, with external users not initially being in the domain, which would mean a registration process. We can handle that from SP, and i assume it would be managed in an AD domain. I'm very familiar with AD and we've done that before with AD and ADLDS. So either separate AD with ADFS, or native AD replica. That's kind of the easy part. They will have 3rd party customers "affiliates" hitting the site, as well as corporate users. I doubt they would want their own AD polluted so i'm fairly sure ADFS is in this picture. They say they have an authentication database though and I haven't gotten a response as to what that is. They control all roles and such in this database. The main thing is they want SSO for internal users and regular sign in for external.
The customer wants to be able to handle accounts themselves. Like making modifying the roles. Password corrections. Usage analysis. Making accounts. Also, self service password resets. I figured FIM could cover all of that. But you say FIM can only be used internally? Or are you saying we need 2 FIM servers, one for the external portal and one for internal intranet use?
The FIM Portal can only be used internally, but that one instance can manage a wide variety of data on behalf of external users (they just can't connect to the Portal). Certainly the FIM Portal can manage identity data for another forest that has no trust relationship with the forest where the FIM Portal is hosted.
One of the first questions here is, where will the external user accounts live? Clearly you don't want to stuff them into the internal AD forest... and setting up a second AD forest is not really desirable--I'd want to use AD:LDS or the like--but ADFS2+ won't use AD:LDS as an authentication store, only AD. So then the choice is to use AD anyway, or use a different STS that you can federate with ADFS and which will accept a generic LDAP user repository (Thinktecture's maybe, or a custom one with WIF).
So, that's the hard part, but ADFS and claims-based authentication are perfectly compatible with the major design goal of SSO and RBAC for internal users to a non-domain-joined set of applications, with forms-based login (albeit through a different intermediate STS) for everyone else.
Steve Kradel, Zetetic LLC
I didn't get the answers I wanted. They are using an MS dynamics DB for user/pwd. We're shelving this until we win the contract but it looks like a complete redesign with no federation, which might make this much simpler than I tought. Maybe an independant AD forest in the colocation. Thanks for the help :)