none
Accessing local domain resources (file / print) with AAD joined device / login?

    Question

  • I am trying to figure out if what I am trying to do is supposed to work and I am doing something wrong or if it isn't supposed to work. In my environment I have a local AD that is connected to AAD / Office 365 via AD Connect and the synchronization works fine. I am doing some testing of Win 10 RS2 / CU in combination with newer Intune MDM stuff. If during OOBE I AAD Join the device everything works fine for AAD resources like auto login and business store access. However I can't access my local domain joined servers for things like file / print. If I look at computer management on the Win 10 device I see the local admin group has the AAD user listed as domain\username like it would if it was local domain joined. However if I try to access server it fails with permission error. If I manually type in domain\username using other user option and same password I am able to access resources. This however is not a good user experience.

    Is this supposed to work? I can't seem to figure it out. Thanks for any help or pointers to documentation.


    Brian Hoyt

    Friday, March 03, 2017 11:25 PM

All replies

  • See detail on AAD Proxy here:

    • Single sign-on to company resources: Users enjoy single sign-on from the Windows desktop to apps and resources in the cloud, such as Office 365 and thousands of business applications that rely on Azure AD for authentication through Azure AD Connect. Corporate-owned devices that are joined to Azure AD also enjoy SSO to on-premises resources when the device is on a corporate network, and from anywhere when these resources are exposed via the Azure AD Application Proxy.


    Mike Crowley | MVP
    My Blog -- Baseline Technologies

    Saturday, March 04, 2017 12:01 AM
  • I believe the scenarios you described (windows file/print shares) usually utilize Windows-generated "access tokens" that pull in information from your AD environment about your user SID, security group membership (to define what you can and can't access), etc... When you are logged into a machine joined to on-prem AD, it passes your access token along to resources also joined to that domain (such as file and print servers) so that they can verify and grant access without require you to type in credentials everytime. Unfortunately, Azure AD works in a fundamentally different way that does not generate access tokens based on your privileges in the on-prem AD. You'll need to setup the Azure AD app proxy mentioned by Mike in order to do anything like that.
    Wednesday, March 08, 2017 5:42 PM
  • Thanks I am going to test this soon and report back.

    Brian Hoyt

    Wednesday, March 08, 2017 11:53 PM
  • The more I read about AD Application Proxy it seems it only works for web based apps. I am looking for file and print services specifically. I found Introducing AzureAD pass through authentication and seamless SSO and am wondering if that is better fit?

    Brian Hoyt


    • Edited by HoytB Friday, March 10, 2017 1:35 AM Fixed link.
    Friday, March 10, 2017 1:16 AM
  • Well I think I answered my own question. Using the latest AD Connect and enabling SSO it seems to allow me to access local servers with my Azure AD token. More testing!!!

    Brian Hoyt

    Friday, March 10, 2017 1:34 AM
  • Well I am back on this doing more testing / troubleshooting. It seems to work with password logins but not Hello based logins. See my other thread https://social.technet.microsoft.com/Forums/azure/en-US/c4f1693b-46dc-4c7b-9467-c7a4d31d2583/azure-ad-seamless-single-signon-only-works-when-password-login-used-but-not-with-windows-hello

    Brian Hoyt

    Thursday, August 24, 2017 9:49 PM
  • Hola a todos.

    No hablo ingles, por lo que use traductor en internet. Mi solución para este mismo problema que reporta HoytB fue el siguiente:

    1. Ir a las propiedades del sistema (clic derecho en Este Equipo > Propiedades)

    2. Cambiar Configuración

    3. Cambiar

    4. Más

    5. ingresar el nombre del dominio local, en el cuadro de texto de (Sufijo DNS principal de este equipo:)

    no tuve necesidad de meter mi maquina al dominio local, solo le agrego este Sufijo de DNS.

    Ahora, lo ultimo que realice, fue agregar manualmente en el modulo de credenciales la clave:

    1. en Inicio buscar (Administrador de credenciales)

    2. Credenciales de Windows

    3. Agregar una credencial de windows

    4. lleno los campos de nombre del recurso de REd, nombre de usuario (dominio\usuario) y clave.

    reiniciamos el equipo y todo listo.

    espero les sirva a ustedes.

    Monday, March 12, 2018 9:55 PM
  • Well I am back on this doing more testing / troubleshooting. It seems to work with password logins but not Hello based logins. See my other thread https://social.technet.microsoft.com/Forums/azure/en-US/c4f1693b-46dc-4c7b-9467-c7a4d31d2583/azure-ad-seamless-single-signon-only-works-when-password-login-used-but-not-with-windows-hello

    Brian Hoyt

    YUUUP!!!  YOU SAVED THE DAY!  I SIGNED OUT, COVERED MY CAMERA, USED MY PASSWORD AND BOOM... I GOT TO MY DC LIKE NORMAL.  THANK YOU!!!
    Wednesday, April 11, 2018 7:39 PM