7 Replies Latest reply on Oct 21, 2016 8:24 AM by duncanbaker

    Azure/Multiple Active Directories

    duncanbaker

      Hey folks

       

      I've been looking for a solution for a situation for a while and had some pointers from generous people but as yet these have not panned out as far as the investigating we have done, so I thought I'd open it up to a wider audience. Let's set the stage:

       

      There is an Azure hosting environment which is made up of the following:
      FM Database server - let's call it FMDB
      FM WebDirect server (two server deployment of course) - let's call it FMWD
      Domain controller server - let's call it DC
      This of course all sits on the same virtual network.

       

      Let's call the company that owns the Azure environment and FM database "Solution Owner". Solution Owner wishes to authenticate using Active Directory (let's shorten this to AD ongoing). So, we turn on AD on DC and set it up with groups, turn on External Authentication in FMS Admin Console, set up groups in Security in the file, and all is good right? Yes, FMS looks out to its local network, finds the directory server etc etc.

       

      But now, Solution Owner would like company ABC to access the database and ABC also wishes to use their On-Premise AD to authenticate. Mmm... How do we do this? Solution Owner effectively has an On-Premise AD, ABC has On-Premise AD - can Solution Owner pull in groups from ABC into its AD so when FM goes out to authenticate it sees the groups from ABC? Possibly with federating?

       

      Assuming that gets figured out, Solution Owner now needs company XYZ to have access to the database. XYZ would like to use AD to authenticate. But XYZ use Azure Active Directory (let's call that AAD) in their company. So, now we have Solution Owner with On-Premise AD, XYZ with AAD and now we need to 'sync' AAD groups from XYZ into Solution Owner's AD. This may be something to do with Azure AD Connect product.

       

      So now, Solution Owner sees that XYZ uses AAD and thinks that's awesome, let's use that. Can FM authenticate against Azure AD, within the same Azure environment as FMDB of course. I'm not sure it can. I think it needs to have a 'traditional' (even if virtual) server on the same network running AD to authenticate against. And now that they are using AAD, can we 'sync' with ABC's On-Premise AD and XYZ's AAD?

       

      So, the issues we're trying to address are:
      Can FM authenticate against AAD for Solution Owner access via any means (sync to trad AD, directly authenticate against AAD, third party software solution)?
      If we have other companies that access the file wishing to use AD or AAD, what options might be open to us here?

       

      We have looked at AD Connect but this didn't seem to pan out - I believe that AAD has a limited number of 'sync' type connections that can be incorporated. I'd like to be proven wrong that this product is unable to do what we need.

       

      We've looked into federating - I think this is a much more involved connection between two companies and again I believe we encountered barriers to achieving our goal when investigating this route. I can provide more details as needed.

       

      We've considered the possibility of building a web app that sits in front of FM that users authenticate against and then get sent to FM (this is more when using WebDirect), but this is a major undertaking, has a whole bunch of issues that need working through and in reality is probably not an option at all.

       

      I feel like we're up against FM's inability to recognize AAD, and we're up against the current limitations of AD/AAD in 'syncing' with other AADs or On-Premise ADs. But, I may be entirely wrong...

       

      If anyone has done (or knows of someone that has done) multiple AD integrations, I'd be very interested in talking with you.

       

      If anyone has any pointers/ideas on what might be possible, what's not possible etc, your input would be greatly appreciated.

       

      If anyone has ideas on third party software that may achieve our goals, I'd be very interested in that.

       

      And I'm open to all other ideas! Many thanks for taking the time.

        • 1. Re: Azure/Multiple Active Directories
          wimdecorte

          duncanbaker wrote:

           

          We've considered the possibility of building a web app that sits in front of FM that users authenticate against and then get sent to FM (this is more when using WebDirect), but this is a major undertaking, has a whole bunch of issues that need working through and in reality is probably not an option at all.

           

          Either way you spin it, it is going to be a major undertaking.  There are no easy answers for your scenario.  Things have be considered very carefully and tested even more carefully because this is the basis of all security..

           

          In essence: FMS can authenticate users against the AD that it itself belongs to (that the machine it runs on is a member server of); whether that is AAD or on-premise AD.  That's the easy bit.

           

          To allow accounts that exist in other ADs you need to either:

          - set up trust relationships between the ADs (and make sure they can talk to each other without much latency).  Trusting other ADs is a big deal and should obviously not be done lightly, all consequences need to be considered

          - or sync everything up to one AD for FMS to authenticate against (may not work that well if the different ADs have the same account names for instance)

           

          Anything else is going to be a bit of a hack.  You can use an authentication service that can send you a SAML assertion but natively FMS is not set up to consume that.  You can roll your own routines but those would not be as secure as the native FMS EA routine.

           

          If there is data segregation going on in the solution so that users from ABC will never need to see data from XYZ then one thing you could also consider is spin up separate FMS instances and let each company use their own FMS so that you can set up authentication for each one separately.

          1 of 1 people found this helpful
          • 2. Re: Azure/Multiple Active Directories
            wimdecorte

            duncanbaker wrote:

             

            We have looked at AD Connect but this didn't seem to pan out - I believe that AAD has a limited number of 'sync' type connections that can be incorporated. I'd like to be proven wrong that this product is unable to do what we need.

             

             

            What sync type are you after that it does not support?

            • 3. Re: Azure/Multiple Active Directories
              duncanbaker

              wimdecorte wrote:

               

              In essence: FMS can authenticate users against the AD that it itself belongs to (that the machine it runs on is a member server of); whether that is AAD or on-premise AD. That's the easy bit.

              Many thanks Wim. Let me tackle each part bit by bit. The above implies that if we have our FMDB in Azure, that we can authenticate against AAD and not run a traditional AD on DC (the domain controller). In our testing it didn't work, but if you're saying we can use AAD then I'll go back, turn off the DC AD and try again using AAD from the Azure control panel. Maybe we just messed up passwords or something. Can you confirm AAD like this should work?

              • 4. Re: Azure/Multiple Active Directories
                duncanbaker

                wimdecorte wrote:

                 

                If there is data segregation going on in the solution so that users from ABC will never need to see data from XYZ then one thing you could also consider is spin up separate FMS instances and let each company use their own FMS so that you can set up authentication for each one separately.

                There is data segregation as you indicate. There is also aggregation of anonymous data/stats across all companies too though. I believe that if we spun up new instances, we'd need a separate FM license for each instance and that instance would need to be within the environment of ABC and the other one within XYZ's environment so FMS could look to the local directory server (or AAD) for that company?

                 

                If we have separate files then we have the task of aggregating data from multiple files and then pushing it back to each file - certainly possible and we've considered a separate environment for each company. Big increase in costs, development and data movement if the above is the correct interpretation, but could end up being the path that has to be taken.

                • 5. Re: Azure/Multiple Active Directories
                  duncanbaker

                  wimdecorte wrote:

                   

                   

                  What sync type are you after that it does not support?

                  I think I may have mis-worded this part, sorry. I believe the issue we encountered when going down this path was that company XYZ's AAD can only sync with up to 10 or so other AADs when using AD Connect. So if that company already has integrations with other companies (or affiliates etc) then they may have maxed out their connection number. In our case that was already a likely scenario so we hit a wall.

                  • 6. Re: Azure/Multiple Active Directories
                    wimdecorte

                    duncanbaker wrote:

                     

                    wimdecorte wrote:

                     

                    In essence: FMS can authenticate users against the AD that it itself belongs to (that the machine it runs on is a member server of); whether that is AAD or on-premise AD. That's the easy bit.

                    Many thanks Wim. Let me tackle each part bit by bit. The above implies that if we have our FMDB in Azure, that we can authenticate against AAD and not run a traditional AD on DC (the domain controller). In our testing it didn't work, but if you're saying we can use AAD then I'll go back, turn off the DC AD and try again using AAD from the Azure control panel. Maybe we just messed up passwords or something. Can you confirm AAD like this should work?

                     

                    I was pretty sure I had it working a while ago so I took my Azure FMS out of storage and fired it up to test again but I can't seem to make tick.  I'll do some more testing later today.  My scenario does not have an on-premise AD.

                    • 7. Re: Azure/Multiple Active Directories
                      duncanbaker

                      A quick update on this. We're looking into this: Azure Active Directory B2B collaboration | Microsoft Azure

                       

                      It might not be entirely ideal but may work well enough until it gets developed further.

                       

                      Still not sure if we can authenticate directly against AAD from FM, so we might be having an on premise AD that is federated (or sync'd using AD Connect) with an AAD, and then we use B2B to add people to the AAD as "guests".

                       

                      We're still working through it, not sure if it will work, but I will post back with the outcome.