NOT A SIMPLE QUESTION: What is the best way to fix duplicate users problem in multi-domain environment? RRS feed

  • Question

  • Disclaimer: This is not a simple question. Although any proposed solution must be simple :-)

    Scenario: Large organization, lots of users, lots of computers, lots of servers, lots of applications, lots of everything. Did I say large organization already? I think I did...

    Bit of History: Active Directory implemented many years ago. At those times it was believed that multi-domain environment is the best. Indeed, each line-of-business gets their own domain. How cool is that? Each LOB has their own private space, their own users, computers, servers, printers, and administrators. Even their own password policy. And of course their own applications that over years created to authenticated against this specific domain. Yes, that's right! Authentication is designed only against specific domain. And to make it even worse, it is using IP addresses of specific Domain Controllers in this domain for authentication!

    How it used to be: Initially it was all good. If user USR-A belongs to line-of-business LOB-A, this user resides in domain DOM-A, and application APP-A (that is authenticate against domain DOM-A) is working perfectly. Another user USR-B belongs to line-of-business LOB-B, they have user account in domain DOM-B, and application APP-B is also working perfectly exactly for the same reason.

    Nova days: even though it looks like original design was solid and making sense, over years this model did not really stayed as it was originally planned. And the reason for this is very simple: user USR-A got need to access application APP-B, and user USR-B required access to application APP-A. Well, remember that application APP-A only works in domain DOM-A? That means that another user account was created for user USR-A - USR-A-B (this account for user USR-A in domain DOM-B), and user USR-B got another account USR-B-A in domain USR-A.

    How it worked: User USR-A never really login to domain DOM-B. User USR-A only login to domain DOM-A. This user only use credentials USR-A-B when accessing application APP-B. User still login to his home domain - DOM-A. But when user USR-A starts application APP-B, user credentials from domain DOM-B is required and this is where user needs to use user account USR-A-B. Besides inconvenience of changing password monthly in accordance with password policy and need to remember 2 passwords (in case they are not the same) this model worked pretty well for many years.

    What happened: 10-15 years ago nobody could think that one day Cloud will come. Even 3-4 years ago it was not that clear when Steve Ballmer was so excited telling us that everything will be in the Cloud soon. But now Cloud services became reality. It is so real that you can almost touch it. Yes, it is here. And it looks like here to stay. And I'm talking about Office 365 and Azure, specifically Azure Active Directory.

    Azure AD: Well, it is not surprise that Azure Active Directory is flat. Remember Windows NT 4.0? Bingo! There are no OUs, there are no domains, there are no forests. No GPOs, no Delegate of Control, nothing what we learned about in year 2000 when preparing for AD exams. Just one big flat container (known as Tenant) that contains all users in one flat list. For this reason I would say Azure Active Directory should be called Azure List of Users :-).

    Challenge: Since Azure AD is flat, there is only one user can be created for one individual. Not many. But remember that we got multiple users? Person A got two user accounts - USR-A and USR-A-B, and person B got also two accounts - USR-B and USR-B-A. So how we supposed to replicated those users to the cloud? If we replicate all domains, we will get multiple users accounts (known as duplicates) in Azure. This is not cool. This will mess up entire Cloud services adoption, and will create nothing but problems for end-users and Helpdesk. And after all it would probably be unsecure too! Remember that we talks about large organization? So if you are looking for John Smith, there are many of those...

    Possible options: After spending several years it became obvious that there are 2 main approaches to address duplicate user accounts issue: either eliminate the root cause by consolidating multiple domains and forests into one single domain (of course all problems will disappear since there is no need to create multiple user accounts in single domain) or deploy something that will allow to masquerade multiple user accounts and present directory to applications as single pane of glass. And there are multiple products on the market that can do that. Of course each of them has different capabilities and works slightly different, but idea is the same: present single identity view to applications so users can authenticate seamlessly to applications.

    Dilemma: while first option (consolidate into single domain and collapse all other domains) seems to be most attractive because it is fixing the root cause (and there is no better solution than fix the root cause) this option seems to be unrealistic. Why? Well, remember those developers who developed their applications to authenticate against one single domain? To re-design and re-deploy those applications it could be years, lots of money and huge impact to business. This does not sounds good. On the other hand, it is very tempting to deploy the "Band-Aid" solution (e.g. NetIQ Access Manager or Virtual Directory Server/Service) because no need to re-design and re-deploy applications, minimum impact to business and reduced cost (comparing to first option), this option has one major pitfall: we don't resolve the root cause. So underlying issue can be actually growing.

    Question: What to do? Fix the root cause (looks good but expensive) or apply workaround (and keep bleeding). Somehow I do believe that there are many (if not all) large organizations with the same set of challenges :-)

    Any suggestions would be much appreciated!


    • Edited by lync15 Tuesday, January 12, 2016 6:27 PM
    Tuesday, January 12, 2016 3:57 PM