none
Azure AD joined system not able to access local domain resources

    Question

  • I have a hybrid domain deployment setup with an onsite domain (Azure AD Conenct server is running 2012 R2, but domain functionality is 2008 R2). Everything is working great so far, we have Password Writeback and SSO enabled, and for domain-joined devices, that's all been good.

    However, we're starting to roll Azure AD joined devices in, and that's where we have trouble. It's successfully linking users (if I type 'whoami' it reports as being the correct onsite user), but if I try to access a network share, it first says 'incorrect username or password' and prompts for a PIN again, and then after typing the PIN, it times out and says 'There are currently no logon servers available to service the login request'. If I manually type in the username and password when it says 'incorrect username and password', it logs in normally and I can access the share.

    Why isn't it correctly handing off the username and password to login? I can type klist and see I have no active kerberos sessions. I have a feeling like something is configured incorrectly somewhere and it's not passing off the authentication properly. The onsite domain is a .local domain.

    I feel like this is a super simple problem that just is like "oh, you have to change X setting" and I'm just blind.


    Monday, April 03, 2017 8:23 PM

All replies

  • Is the Azure AD user logging on with a password or PIN?
    Wednesday, April 05, 2017 3:53 PM
    Moderator
  • Logging in with a PIN. Is there something that has to be enabled on the local domain side to allow PIN authentication?
    Wednesday, April 05, 2017 8:34 PM
  • Ensure that the NGC cert enrollment has completed. One way you can verify is, through certutil -user -store My.
    If you see any cert which has a subject and issuer of the form S-1-5… then that means the enrollment didn’t succeed.
    Thursday, April 06, 2017 4:52 PM
    Moderator
  • Okay, it looks like that happened.

    I see:

    Issuer: CN=S-1-12-1-519359463-1247027319-2330935967-4196090160/01d92bac-a2c7-4966-a3bf-417dc61bd288/login.windows.net/ee3f0e42-868a-4be2-9d44-bc066b29e552/joe.user@domain.com

    How do I resolve this? I have two certificates, that one and the one from Airwatch, which the device gets enrolled in when it joins Azure AD.

    Is there any way to check to see if these devices are enrolled?

    Thursday, April 06, 2017 10:31 PM
  • If I head into "Mobile Device Management for Office 365", I see the device, but the device is actually being managed from AirWatch. I see the device in AirWatch as well. Due to the fact I am type whoami, I know that the device sees me as the on premises user.

    How do I fix this error?

    Thursday, April 06, 2017 10:45 PM
  • A deployment requirement for Hybrid organizations deploying Windows Hello for Business to get on-prem access is to either deploy Windows 10 domain controllers OR use Intune to deploy certificate enrollment using SCEP for the Windows Hello for Business key with down-level domain controllers.

    Neither of the certs you have below are the certificate that is required for Windows Hello for Business and are device enrollment certs. The device appears to be ppropriately enrolled in MDM and with Azure. It’s the user Windows Hello for Business cert that needs to be enrolled.

    The first thing to determine is if device registration occurred.  This can be done from the command line using “desregcmd /status”.  It sounds like the device registered because you created a PIN.

    The next step is to determine if Windows Hello for Business is configured for key-trust or certificate trust.  I’m not sure Airwatch configures this.  The MDM (Intune) sends down an certificate profile that defines the KSP as Windows Hello for Business and the certificate contains the Smart Card Logon EKU.  If that is not configured, then the configuration assumes key-trust.  If configured the intent is cert-trust, there are additional configurations configured within a certificate profile, that provides the MDM client with the Certificate Registration Point and the NDES URL, which is used to enroll WHFB authentication certificates.

    The client uses the certificate it receives from the NDES server for on-prem authentication.

    Without the certificate, the on-premises domain needs an adequate number of Windows 2016 domain controllers and must have user key write back enabled. 

    Also, regardless of trust model, all domain controllers need to have a certificate that includes the Kerberos Authentiction EKU so the non-domain joined (ADJ) computers can perform strict KDC validation.

    Wednesday, April 12, 2017 11:26 AM
    Moderator