Forum Discussion

Alexander Filipin's avatar
Alexander Filipin
Brass Contributor
Jul 06, 2017

AAD Application Proxy and B2B Users

Just want a confirmation the following would work:

Invite B2B user

Create DISABLED AD Account on local ADDS with the UPN of the invited B2B user (Automation via SCIM Provisioning)

Use AAD App Proxy to provide on-premises application to B2B user

  • Hi, I assume you are looking to use the app proxy for organizations with on-premises apps which are using Windows authentication.  We are currently working on the documentation for this scenario which should be posted to docs.microsoft.com shortly.   In principle, creating an account in a AD domain corresponding to a user in Azure AD, including a guest user, would enable the app proxy to match the user coming in from Azure AD and use KCD for impersonation and permit that user to then access Windows integrated authentication, however there are a number of account lifecycle subtleties here.  So even if you see the app proxy is able to permit the communication flow, I'd suggest waiting for the documentation as there are a number of deloyment considerations and best practices to look at (e.g., what container to put the users in, when to deprovision the user from AD, how to avoid RID exhaustion and end user confusion about "All authenticated users" etc)  Feel free to reach out to us if you have additional questions.  Thanks, Mark  

  • Hi, I assume you are looking to use the app proxy for organizations with on-premises apps which are using Windows authentication.  We are currently working on the documentation for this scenario which should be posted to docs.microsoft.com shortly.   In principle, creating an account in a AD domain corresponding to a user in Azure AD, including a guest user, would enable the app proxy to match the user coming in from Azure AD and use KCD for impersonation and permit that user to then access Windows integrated authentication, however there are a number of account lifecycle subtleties here.  So even if you see the app proxy is able to permit the communication flow, I'd suggest waiting for the documentation as there are a number of deloyment considerations and best practices to look at (e.g., what container to put the users in, when to deprovision the user from AD, how to avoid RID exhaustion and end user confusion about "All authenticated users" etc)  Feel free to reach out to us if you have additional questions.  Thanks, Mark  

    • Alexander Filipin's avatar
      Alexander Filipin
      Brass Contributor
      Hi Mark,
      create to hear this :)
      Thats exactly what we are looking for. We (Oxford Computer Group Germany) just started working on a SCIM client to get some automation into this for our customers.

      Looking forward to see it on docs!
    • Alexander Filipin's avatar
      Alexander Filipin
      Brass Contributor
      And for the app proxy to use KCD for impersonation the account could be disabled or?
      • Mark_Wahl's avatar
        Mark_Wahl
        Icon for Microsoft rankMicrosoft

        It is correct that the user does not need to authenticate themselves to the AD DS domains.  However the documentation on the combination of AD user account attributes that will be supported with Azure AD App Proxy for Windows integrated auth applications will need to be updated for the B2B guest scenario.  (Typically for employees accessing on-premises apps, the users have been enabled on-premises as well as in Azure AD, so this issue has not yet showed up -- until now when we have guests).  We'll need the Azure AD app proxy for guest scenario validation to be completed so we can ensure the combination of attributes work together, since KCD scenarios are often difficult to get working on first try particularly for multi-domain/multi-forest scenarios.  Feel free to reach out to Sarat or I offline via email if you wish to discuss further.  Thanks, Mark 

    • Hi Mark, just wondering if and where I can find the update documentation about this topic.

       

      Thanks in advance,

      Ronny 

      • R K's avatar
        R K
        Copper Contributor

        Any updates from Mark Wahl on the document?

         

    • Alexander Filipin's avatar
      Alexander Filipin
      Brass Contributor
      On-premises application based on windows authentication
      AAD App Proxy configured AAD as Preauth method
      Internal Auth confiured as Integrated Windows Auth.

      This would allow to provide a internal "legacy" app to a B2B user
  • I Tested this in my lab today and made things work for guest access to on premises applications via Integrated authentication as well as federated authentication by creating a shadow user in the on-premises directory.

    However, the UPN passed back to my on-premises applications seems to differ in each case.

     

    Federated Authentication seems to be passing my original UPN:

    guest.user@guestdirectory.com

     

    while Application Proxy is passing my guest UPN from the test tenant:

    guest.user_guestdirectory.com#EXT#@mydirectory.com

     

    So for now, I ended up having two different Accounts in my on-premises directory. I thought about using a different attribute, but application proxy only gives me a limited choice and I think UPN is still the most convenient pick.

     

    Any Ideas on how to overcome this? 

Resources