S02E29 - Beginners Guide to Accessing On-Premises Resources with Azure AD Joined Devices - (I.T)

preview_player
Показать описание
Sorry about Adam's keyboard noise and yes, this could be a very short video but we felt like there are people who could use a more in-depth discussion.

00:00 - Intro
00:10 - Jóhannes Geir Kristjánsson introduction
01:10 - Access on-premises resources from an Azure AD-joined device
02:36 - Windows admins discord
04:31 - Migration process
06:40 - Blockers
10:24 - Lab environment
15:50 - Install Azure AD Connect
37:57 - Assign licences
52:40 - Enable single sign-on
1:03:38 - Internal websites and certificates
1:09:08 - Wrap up

Visit our websites and social media for more or to get in touch with us

Jóhannes Geir Kristjánsson - Owner of the Windows Admins Discord Server

Steve Hosking - Microsoft MMD Team

Adam Gross - Microsoft MVP - Enterprise Mobility

Ben Reader - Microsoft MVP - Enterprise Mobility

Jake Shackelford - Desktop Engineer
Рекомендации по теме
Комментарии
Автор

Your video basically summarizes our school's scenario: migrating to modern endpoint and user management without having to severely disrupt the work routines of users accessing local resources. Thank you Intune Training, and thank you to all of the constructive commentators on this page!

brianplaster
Автор

Holy crap!!! This is exactly what i needed to see. We are on a decision point between aadj and hybrid because of the onprem resources.

JessieS
Автор

Awesome stuff especially working through the inevitable roadblocks!

tommccann
Автор

Thanks for another informative video guys. I set this up last year and also turned on the integration with Hello for Business, it works a charm without Hybrid Joined Device. I am now looking to only complete Azure AD joins for new/rebuilt devices with mostly on-prem synced users. One thing for folks to note is that if you have an Azure Ad only user they can't be added to on-prem based AD Groups easily, if at all.

BTW I think the DNS issue was that you were typing .net instead of .lab at the end of the url, you had set your domain as asd.lab :)

BeastleeUK
Автор

G'Day guys, good to hear windows admins is still running! Ill join back soon!

danpadgett
Автор

This is exactly what we were looking for.
Great Video thanks for everything

DeeJayJsBrown
Автор

Whoa.. this guy helps me all the time!

Sladeofdark
Автор

You are awesome .. thanks for the material

rfrancoit
Автор

Hi Adam. Would you mind sharing your powershell script that you used to set the DNS suffix search list? I really appreciate all the Intune content!!!

intunestuff
Автор

All the kerberos stuff is a red-herring, as you're trying to browse the DC by IP address. Hence Kerberos won't be used. Pretty sure that's why klist is coming up empty - you authenticated via NTLM instead due to that IP.

This would have been so much smoother if you had checked and gotten DNS working properly early-doors... you were blowing past log entries at @50:39 showing name resolution failures. Having your DC dish out IP with DNS for your client would have been worthwhile for your lab I'd have thought.

It does raise the issue tho of scripts that you deploy from Intune *that run as SYSTEM/device* won't be running in a domain-joined computer context, and if they try to access a network resource (eg file server) then I expect they're gonna fail - so if your package is due to be pulled from a file server, then... oooops? Will give that a try this afternoon I think. Worth trying a "psexec -i -s cmd" and then seeing if you can browse your share.

lansingr
Автор

It was funny how you have been trying to add the UPN in Domain and Trust - well I did it few days ago. Great video still :D!

mjay
Автор

examples of what a pain it is to set this up and get it to work.

jwspiker
Автор

Hi, so getting to on prem resources is the easy part.. :) what about on prem resources trying to access an azureAD device back when its on the network - e.g. NAC or discovery tools that are query using WMI ?

gaddayan
Автор

Did you guys release a newer version of this video?

jamesg
Автор

One big draw back with this is where the identity source resides. Since on-prem is still controlling identity you need a line of sight to the server to do PW resets. May not be a big deal for some orgs but it's only becoming more of a concern with remote work only becoming more and more of a concern.

Great video though guys. Long time viewer, first time commenter. 😁

MainStageSniping
Автор

what just happened? lol. Great series guys. So are you saying you dont need to Domain Join AAD devices? I'v seen no evidence the Domain Join option in InTune works...

mrkingskintim
Автор

One suggestion when install AAD Connect would be to install it on the same server that hosts the FSMO rules, just to avoid replication issues

thedude
Автор

thanks for video! its means what is AAD devices need to access on-prem service (like shared drives) is enable sync with password and the device should be able to communicate with on-prem servers like ping! is this right?

ehababumoailish
Автор

So since device is not domain joined, will it pick up user based GPOs? I’m thinking not since it is authenticating against AAD, not on premise AD. The on premises AD server never “sees” you logging in. And how do you do drive mappings? Logon script pushed from Intune?

matthewbrice
Автор

Hi Adam, very useful again!
Just one short question: do you know the domain functional level requirement to have TGT on a AADJ-device?

dakozh