Home

Azure AD Joined device and authenticate on-premise AD.

%3CLINGO-SUB%20id%3D%22lingo-sub-308946%22%20slang%3D%22en-US%22%3EAzure%20AD%20Joined%20device%20and%20authenticate%20on-premise%20AD.%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308946%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI'm%20working%20on%20a%20new%20Workplace%20configuration%26nbsp%3Bbased%20on%20Windows%2010%2C%20Azure%20AD%20and%20Intune.%20Users%20should%20be%20able%20to%20Join%20their%20Windows%2010%20device%20to%20Azure%20AD%20and%20auto-enrolled%20to%20Intune.%20So%20far%20so%20good.%20We%20still%20are%20in%20transition%20migrating%20our%20date%20to%20SharePoint%2C%20so%20users%20should%20have%20access%20to%20the%20data%20shares%2C%20unfortunately%2C%20the%20first%20time%20after%20the%20users%20logs%20in%20(after%20joining%20Azure%20AD%20during%20oobe%20wizard)%2C%20they%20have%20no%20access%20to%20the%20on-premise%20shares.%20However%2C%20after%20the%20second%20logon%2C%20the%20users%20has%20access%20to%20the%20shares.%20I%20guess%20there%20is%20no%20kerberos%20ticket%20to%20authenticate%20againt%20the%20on-premise%20AD%20after%20first%20time%20log%20on.%20I%20wondering%20if%20this%20is%20normal%20behaviour%2C%20or%20should%20this%20normall%20worked%20the%20first%20time%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-308946%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%20AD%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESSO%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-360911%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Joined%20device%20and%20authenticate%20on-premise%20AD.%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-360911%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F869%22%20target%3D%22_blank%22%3E%40Chris%20Webb%3C%2FA%3E%26nbsp%3Bwe%20also%20had%20to%20spend%20some%20time%20to%20get%20it%20to%20work%20but%20we%20got%20it%20working%20now.%20There%20were%20some%20caveats%20that%20is%20not%20clearly%20mentioned%20in%20the%20articles.%20Are%20you%20trying%20to%20get%20it%20to%20work%20using%26nbsp%3B%3CSTRONG%3Ekey%20based%3C%2FSTRONG%3Eor%26nbsp%3B%3CSTRONG%3Ecertificate%20based%3C%2FSTRONG%3E%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308987%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Joined%20device%20and%20authenticate%20on-premise%20AD.%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308987%22%20slang%3D%22en-US%22%3EThanks.%20I'll%20check%20the%20msDS-KeyCredentialLink%20attribute.%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308980%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Joined%20device%20and%20authenticate%20on-premise%20AD.%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308980%22%20slang%3D%22en-US%22%3EThis%20article.%20Never%20could%20get%20it%20working%20yet%2C%20ran%20out%20of%20time%2C%20but%20plan%20to%20get%20it%20going%20at%20some%20point%3A%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fsecurity%2Fidentity-protection%2Fhello-for-business%2Fhello-hybrid-aadj-sso-base%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fsecurity%2Fidentity-protection%2Fhello-for-business%2Fhello-hybrid-aadj-sso-base%3C%2FA%3E%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308978%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Joined%20device%20and%20authenticate%20on-premise%20AD.%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308978%22%20slang%3D%22en-US%22%3EYeah%2C%20I%20found%20an%20article%20that%20is%20supposed%20to%20get%20it%20working%20but%20couldn't%20get%20it%20right%20in%20my%20Test%20domain%2C%20it's%20throwing%20different%20error%20than%20my%20prod%20so%20not%20sure%20if%20it's%20related%2C%20but%20I'm%20determined%20to%20support%20PIN%2C%20because%20passwordless%20etc.%20coming%20in%20the%20future%20is%20going%20to%20depend%20on%20that%20Windows%20Hello%20coming%20across.%20%3CBR%20%2F%3E%3CBR%20%2F%3EI%20guess%20the%20first%20login%20issue%20could%20be%20related%20to%20that%20attribute%20not%20getting%20wrote%20to%20your%20AD%20originally.%20Not%20sure%20when%20that%20takes%20place%2C%20or%20if%20it%20happens%20right%20away%20etc.%20But%20just%20a%20hunch%2C%20because%20I%20know%20that%20only%20exists%20when%20Azure%20AD%20Joined%20with%20Intune%20and%20that's%20what%20it%20checks%20the%20token%20with.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308975%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Joined%20device%20and%20authenticate%20on-premise%20AD.%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308975%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Chris%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EPIN%20didn't%20worked%20at%20all.%20I%20also%20forced%20the%20users%20to%20use%20password.%20I%20think%20you%20should%20configure%20Hybrid%20Windows%20Hello%20before%20you%20can%20use%20PIN%20to%20authenticate%20with%20your%20local%20AD.%26nbsp%3B%26nbsp%3BThis%20is%20only%20working%20with%20a%20Windows%202016%20DC.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-308971%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20AD%20Joined%20device%20and%20authenticate%20on-premise%20AD.%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-308971%22%20slang%3D%22en-US%22%3EIf%20I%20had%20to%20guess%20it's%20due%20to%20the%20delay%20of%20the%20msDS-KeyCredentialLink%20to%20get%20wrote%20back%20to%20your%20onPrem%20AD.%20%3CBR%20%2F%3E%3CBR%20%2F%3EI%20do%20have%20a%20question%20as%20well%20for%20you%2C%20are%20you%20using%20PIN%20login%20and%20still%20able%20to%20get%20access%20to%20resources%3F%20I%20know%20I%20cannot%20get%20the%20PIN%20to%20work%2C%20and%20have%20to%20force%20users%20to%20use%20Passwords%20for%20the%20on-prem%20ticket%20to%20match%20up.%20Also%20wondering%20if%20first%20time%20they%20log%20in%20they%20setup%20PIN%20in%20your%20instance%2C%20but%202nd%20time%20login%20with%20password%3F%20Which%20might%20be%20same%20issue%20here.%3C%2FLINGO-BODY%3E
Angelo Lelieveld
Occasional Contributor

Hi,

 

I'm working on a new Workplace configuration based on Windows 10, Azure AD and Intune. Users should be able to Join their Windows 10 device to Azure AD and auto-enrolled to Intune. So far so good. We still are in transition migrating our date to SharePoint, so users should have access to the data shares, unfortunately, the first time after the users logs in (after joining Azure AD during oobe wizard), they have no access to the on-premise shares. However, after the second logon, the users has access to the shares. I guess there is no kerberos ticket to authenticate againt the on-premise AD after first time log on. I wondering if this is normal behaviour, or should this normall worked the first time?

 

 

6 Replies
If I had to guess it's due to the delay of the msDS-KeyCredentialLink to get wrote back to your onPrem AD.

I do have a question as well for you, are you using PIN login and still able to get access to resources? I know I cannot get the PIN to work, and have to force users to use Passwords for the on-prem ticket to match up. Also wondering if first time they log in they setup PIN in your instance, but 2nd time login with password? Which might be same issue here.

Hi Chris,

 

PIN didn't worked at all. I also forced the users to use password. I think you should configure Hybrid Windows Hello before you can use PIN to authenticate with your local AD.  This is only working with a Windows 2016 DC.

 

Yeah, I found an article that is supposed to get it working but couldn't get it right in my Test domain, it's throwing different error than my prod so not sure if it's related, but I'm determined to support PIN, because passwordless etc. coming in the future is going to depend on that Windows Hello coming across.

I guess the first login issue could be related to that attribute not getting wrote to your AD originally. Not sure when that takes place, or if it happens right away etc. But just a hunch, because I know that only exists when Azure AD Joined with Intune and that's what it checks the token with.
This article. Never could get it working yet, ran out of time, but plan to get it going at some point: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybri...
Thanks. I'll check the msDS-KeyCredentialLink attribute.

@Chris Webb we also had to spend some time to get it to work but we got it working now. There were some caveats that is not clearly mentioned in the articles. Are you trying to get it to work using key based or certificate based?

Related Conversations
Extentions Synchronization
Deleted in Discussions on
3 Replies
Tabs and Dark Mode
cjc2112 in Discussions on
35 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies
Stable version of Edge insider browser
HotCakeX in Discussions on
35 Replies