Centralized Authentication

We run a private cloud environment for multiple clients. We have a resource domain that provides access to shared applications such as Citrix, Exchange and VDI. The clients are segregated from each other with their own user domains that have a forest trust to the resource domain.

I'd like to do away with these trusts. They are difficult to maintain and create firewall swiss cheese. I'm looking for a solution that can communicate with each user domain's AD and provide authentication to the resource domain's applications. I've been researching Password synchronization, Enterprise Single Sign On, ADFS and RADIUS solutions but haven't quite found what I'm looking for. Has anybody got close to achieving this or have some other buzz words for me to investigate?
Who is Participating?
page1985Connect With a Mentor Commented:
Microsoft's Office 365 offering does this with a mix of Forefront Identity Manager (to synchronize passwords and accounts) and Active Directory Federation Services.  However, in order for this model to work, all applications in the resource forest must support ADFS token-based or claims-based authentication.  Meaning, the application must be able to authenticate using something other than just straight up Active Directory/Windows Integrated authentication.

Most major Microsoft products (Exchange, SharePoint, Lync) support ADFS, but it's still very difficult to configure.  Reality is, either doing forest trusts like you are now or combining into a managed domain with OU security will be the easiest ways to do it.

I used to operate strictly on the forest trust model (like you are now), but I now have a hybrid trust/managed environment.  For customers that have their own on-premise domain, a one-way forest trust is used.  For smaller customers, or customers who do not care about single sign-on, a managed domain with locked down OUs is being utilized.  I accomplished this by creating a "Business Units" OU and within it a separate OU for each customer.  Customers also have their own Administrators, Users, Computers, Account Operators, Backup Operators, Services, Batch Logon, and few other "builtin" groups so that they can manage rights within their slice of the kingdom.  Additionally, they're given GPOs which prevent users who do not belong to one of their groups from being able to login to their systems.  This can be very convenient because, in the event you get partner companies as customers, you can delegate access in one business unit to users in another business unit (at that customer's request, of course).
This can be done with a combined single domain, but rather than firewall swiss cheese, it becomes permissions swiss cheese because instead of a separate domain, each business unit has its own OU which then must be locked down to prevent cross-client snooping.
mrpez1Author Commented:
Thanks for the comment but not really an option due to client requirements and as you suggest a single domain has the same issues with OU permissions.
mrpez1Author Commented:
Thanks for the info. Not sure I'm going to find what I'm looking for. Validation of our current design is a nice consolation prize.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.