Thinking about Intune Autopilot ? Do NOT Domain Join!
Вставка
- Опубліковано 6 вер 2021
- Azure AD Joined devices are just as capable of accessing on-premises resources like file-shares, printers, apps, etc. as Domain Joined or Hybrid Devices.
There is no need to join your computers to your on-premises domain to allow access to on-premise resources. It's not a requirement, and it's not a good idea.
#SayNoToDomainJoin
The Cloud Management Community is YOUR community for Cloud Management, Mobile Device Management and Microsoft Endpoint Manager. Join the discussion on Twitter (@the_cmcommunity) and subscribe to be notified when we go LIVE.
Dean Ellerby is a Microsoft Certified Trainer, Organiser at CloudManagement.Community, Contributor at Petri.com and a Workspace Solution Architect at CDW UK. He's on Twitter @dean_ellerby. Any views or opinions expressed here are his own. - Наука та технологія
![ЛЕБЕДЕВ у ДУДЯ: муху не обманешь 😁 [Пародия]](http://i.ytimg.com/vi/E74h5fvVrqs/mqdefault.jpg)
Cool stuff! Thanks for sharing.
There are some IT admin tasks that can only be accessed/managed via on-prem joined like editing Certificate Services templates and editing GPO WMI filters. Also the user experience for AD management isn't as nice as domain joined (always need to specify domain, auto discovery of things like DHCP servers, DNS, CS doesn't work). For end users, definitely this is a great experience (unless you have on-prem printers that need to be deployed). Universal Print is a solution it can be costly as it's per print.
While I agree to an extent, I've reached a point with intune that I can deploy pretty much anything. Including certs and even local printers on the print server.
@@jgould30how do you deploy local printers with Intune? That’s been a pain for me for years.
@@ACBCallahan I just literally went through this and I ended up setting up PowerShell scripts to detect, install, set default preferences, and remove the printers as an Intune Win32 App and works like a charm.
@@kingdavid52was this using a local printer server or adding by direct IP? Would love to chat more if you’re willing.
Very nice. Can you show printing demo too? Also can you show what happens to local admin group right after you aad join the pc?
Recently had this problem where a number of users were created on the domain to be given E2 email license in a hybrid setup. The problem is when disabling inactive onprem users those E2 users are also disabled.
I have AD Connect and SSO works flawlessly, in addition you can now use cloud Kerberos to allow for using windows hello to access domain resources.
Mind blown! Thank you sir....more great stuff...new follower!
Welcome aboard!
Thanks for the Video. Me myself was lately looking in to authenticating to a ad domain from a aad joined machine by using Certificates and WHfB KDC Authentication and it works great. But you don't use any certificates do you?
What i'm curious of what build of windows 10 client do you use in your video.
Is it a 21H2 client and is this a example of the new Windows Hello Cloud Connect. What let you seamlessly authenticate to ad from AAD joined devices.
I'm just asking because i'm very interesting in the new WhfB Cloud connect. And so far I can see in you video there is no way your marketing users could just jump to the file share without any type of authentication prompt. So I thought is the the new Whfb Cloud Connect.
Suddenly, all azure AD joined machines prompt for username and password when they access the share path like print server. What might be the reason for that.
Thanks in advance
Hi, no it did not, I assume the domain is the same as the fqdn of the tenant, it then used the you entered which will have come from ADconnect sync. However you setup hello for business next time you log in using hello pin it will prompt for credentials. Which you can enter and store. Another way is to setup a key share trust and it will allow you access to local resources however you will need to wait up to 30 minutes before the resources are available as the workflow relies on adsync to occur
How about your Intranet websites ? users are too used to leveraging on prem SSO while accessing intranet sites which they have to either move away from or use Windows Hello for Business cloud Kerberos trus
My biggest issue is I use PDQ Inventory and Deploy to install and keep applications up to date as well as keeping an inventory of devices. So, as far as I am aware, I have to keep them domain joined if I want to keep these features, yeah?
PDQ Inventory and Deploy support non-domain joined devices (as does ConfigMgr actually). You just need to add the local admin info to PDQ. See below:
help.pdq.com/hc/en-us/articles/360058301191-Working-with-Non-Domain-Workgroup-Machines
Like always too simple yet too awesome. Could you please showcase different delivery optimization techniques considering clients are co-managed ?
Agreed, so simple. 👍😀
I plan to make a video demonstrating how to manage co-managed devices on the internet, which will cover delivery optimisation and that kind of thing. It should be done in a few weeks
Eagerly waiting for a video on Dlvry optimazation 👍
@@someshpahak +1
Thanks for the information. I was expecting a prompt to login for the second user.
I'm guessing that the only thing the client computer won't get is on premises GPOs.
Exactly. Take a look at this video for an update: Hybrid cloud Kerberos trust deployment - Say NO to Hybrid Azure AD Join!!
ua-cam.com/video/66I2P6XjTyY/v-deo.html
Do you always have to use that \\cm1\ to access the file shares ? What about the printers… l am actually having the issue where my autopilot devices cannot connect to my on Orem printers for the same reason… 😢
No, CM1 was just an example of a file share. Any on prem fileshare should work. I don’t actually have any enterprise printers at home to test with, so I can’t verify that with a video, but I know a lot of organisations who do have printer access working from AADJ only devices.
Are there any pre requisites for this scenario to work? The pc doesn't need to hybrid joined but is AAD connect with password hash sync a requirement with devices object being synced to the DC??
The requirement is for the user to be synchronised via AAD Connect. The device identity isn’t being used here. Try it out… 😀
(1) - Can you do this test again, but more detailed:
1. is the file server AAD joined or just local AD join ?
2. What's the shared setup & security, please remove everyone group or any other group those users in ?
3. Try a different VM per user
(2) - Can you make all device AAD joined, no local AD, and still create shares and access them ????
Thanks for the video. Again great topic. So we can access files and printers. What about GPO?
Yes - file-shares, printers, web apps, most of the stuff users need to access on-premise is accessible via AAD-only devices, without much configuration.
GPO is a different topic, but that's a fantastic suggestion!
In summary, my belief is that GPO is not required. If you're on Twitter, follow Kim Oppalfens (@TheWMIGuy) for some fantastic insight on the topic.
Whilst GPO is not required, we can leverage Intune, proactive remediations and baselines to achieve a goal. The question is (as Kim discusses), is the goal in the Modern world, the same as the Old world?
I shall do a video on the alternatives to GPO. Thanks Imran.
Great video, but I am not sure how you had connectivity to your DC without a VPN since the autopilot device is not in direct line of sight with the DC?. Can you advise how you did this?
Should have been more clear. I had connectivity because I was in the same vlan. This was simulating using a “cloud only” device, but being in the office.
So my only question for this that seems to be left out is what is configured on the local server that allows it to speak to the AzureAD joined machines? I'm assuming you've configured AzureAD connect so that authentication is happening to identify your cloud user with onprem domain.
Great question. Yes - Azure AD Connect is in place on a separate server to handle synchronisation of users. The users I’m showing are on-premise users that have a synchronised identity.
Other than that, there is nothing configured to specifically allow this demo to work. It is all handled natively, and that’s the point I’m trying to get across in this video.
Azure AD devices are much more capable that some organisations think…
So to be clear, the users are still on-prem users, synced to Azure AD? Our issue is users that are just in Azure AD that need to access on-prem resources (files and RDP). It seems that's still not possible.
@@timwhite8 yes. On prem users that are synced to the cloud. I haven’t tried an AAD only user; I’ll try that next !
@@theCMC And it definitely wasn't a jab at you just to be clear. Just want to make sure that less senior people aren't seeing this video and thinking that all they need to do is just connect to the resource. There are other backend things that are at play, but I do love the intent. We run across clients all the time that for some reason want to hold on to the legacy idea of doing things and lean straight into the Hybrid join conversation so I have to remind them those legacy ways have drawbacks such as line of sight with the domain controller to allow authentication while cloud-only means you can be anywhere in the world and authenticate.
@@tbrown4305 no problem, I love the questions and think they help the audience understand the concepts better. I’m only one person, with one view and perspective, and I’m willing to learn in public.
That said, it looks like we have the same thoughts on this one; i just wanted to make a video with a very specific point :-)
Do you have any suggestions on how to get a decent software inventory report for intune joined devices? They discovered apps report is useless. I’ve used the Defender ATP portal but that’s not really a report. Trying to determine what’s installed on machines is a pita.
Intune is awful at software inventory. Defender for Endpoint is better, but no where near as good as ConfigMgr.
Have you considered ConfigMgr?
Intune is our new baby, it will replace the Desktop Central which has the edge in terms of software and hardware inventory
Ninja One (RMM) provides an accurate Software Inventory
So how did you set it up ??
Very interesting video. Thanks.
But now I'm comfuse. The share is a local resource, not it the cloud. So the ACLs are set locally and your user gets access in theory as per the token than the local DC should be giving to that user.
So, ok the computer does not need to be replicated into AD and Azure AD, but the user yes. Isn't it?
And who is authenticating on your test to the user, the local AD or your Azure AD. Did you have connectivity to the local DC when doing the test?
Thank you so much in advance.
Good questions! I admit I could have explained the set up a little better now that I’ve had some great feedback like this.
The user was born on premise and synchronised it Azure AD, so the DC was the authority for that user.
So yes, whilst we don’t need to join a computer to the domain to access on premise resources, the demo I gave here does require the user to be born on premise, and synchronised to AAD.
I did have connectivity to the DC when testing.
@@theCMC Thanks for the quick answer. Congratulations for your channel. You are doing an amazing job. I have seen some other videos regarding OSDCloud and those are very, very interesting. Keep going.👍
Wow times have changed for the better. What domain level are you running in this lab?
@@rob-123 I think it’s 2016 FFL
Dean, hope you are doing well. Thanks for the video. I figured this out a few months ago. But I ran into one issue when I authenticate users with the PIN or any other biometric - this does not work. When I try to open the shared folder, it would prompt for the credentials. Do you know anything about that?
If I log in with the user using a password, it works. thanks!
You're welcome.
It's probably best for you to read this incredible series by @byteben - there is a section on the issues with WHfB.
msendpointmgr.com/2021/08/15/sso-to-domain-resources-from-azure-ad-joined-devices-the-mega-series/
this only works if you have line of site to a dc in your on-prem domain yes? Lets say you domain is cloud based, you have no onprem dc's or adconnect servers. This won't work. Or am I wrong?
The demonstration here relies on the User identity being based on an on-premise DC, and line of sight with a DC is required, yes.
Can you explain how did you configure AD connect is it PasswordHashSync or Passthru Auth? i normal sit i woudl say it cannot work AS you are logging to Azure joined machine using AAD token. token idea does not exists onprem so KRB must be used for the user to get TGS, wireshark trace would be usefull to see auth flow. imho it can only work if you have pass thru auth. Regarding shares - you are showing local rights for the users on Sec tab, share tab could be set for everyone which would explain why its not asking for permissions to list folders
Hi Michael,
AADConnect was configured to use Password Hash Sync, not Passthrough.
For more information, please see this blog by Ben Whitmore and Michael Mardahl.
msendpointmgr.com/2021/08/15/sso-to-domain-resources-from-azure-ad-joined-devices-the-mega-series/
Is this possible without any sort of on-premise domain whatsoever?
Hi, can Azure AD joined devices access PKI certificates from an on-premises CA Server? Our corporate wireless requires a user and device certificate.
Hi Julio,
This is possible, but probably not via the the current method that you’re using to enable the device to auto enroll for a certificate. Instead, you’d need to leverage Intune to deploy a certificate via SCEP or PKCS.
if do not need to join laptop to domain which installed through Autopilot, does it mean that my Domain ID will not be recognized by the autopilot installed laptop?
This depends. As you can see in the video, the users domain identity is recognised by the on premises resources, like file shares.
The computer device identity will not have an on premises account, however.
@@theCMC Thanks for your reply. Yes I can see that file access is possible. We need to use an application on the laptop which required to add an a Domain Windows ID to Local Administrator group and also to DCOM setting. Does it mean that it's not possible or there's actually need some setting required in Intune manager?
Does this work with Exchange and Outlook on-prem?
Yes. Your users are domain users still.
I'll assume you logged in with password, not PIN. I tried to roll out 100% Azure join, but had to roll that back for laptops that were onsite that needed access to On-prem resources. The main reason was the fileshare owners were given a tool to manage share permissions that only works on domain joined PCs. That tool put the onus for managing permission on the share owners instead of IT. We don't have time to manage the 100s of shared we have. I did roll out a 100% Windows Hello policy. My most frequent ticket now is "can't access printers/Wifi" due to them using PIN to login. Is there a way/policy to default to password if they are onsite?
Implement windows hello cloud trust, that way they can access on premise resources with hello
Yes. Do that. I made a helpful video. It’s super simple.
Hybrid cloud Kerberos trust deployment - Say NO to Hybrid Azure AD Join!!
ua-cam.com/video/66I2P6XjTyY/v-deo.html
Please can you advise how this actually works? Is this done via a V-Net in Azure that is linked to on-prem network? Thanks
I think you may be over-thinking it. Apologies - I could have explained the scenario a little better in the video!
We have some servers on-premise, joined to a domain. They host a file share.
We have a Windows 10 computer, which is not domain-joined, but is Azure AD joined. I put them in the same LAN so that they could communicate directly; similar to if the Windows 10 device was a laptop of a user who was sat in the office, and the office had connectivity to the server hosting the file share.
In that scenario, it just works. There is no trickery or magic - it just works. That's the point I'm trying to get across here.
HOW it works, is another matter. I intend do a video on that another time 😀
@@theCMC ahh you were on the same LAN, understood! For remote users I guess a VPN would then suffice. Cheers 👍
Yep, remote would require a VPN.
I'm hoping to do a demo of accessing remote stuff later - this was really just stating and demonstrating something simple, yet often misunderstood.
@@theCMC appreciate it. Thank you
@3:38 - two things:
1. on the server do a "dsregcmd /status"
2. on the workstation do an "ipconfig /all"
In a bigger company there might be more services than SMB. Some of them rely on on-prem characteristics, like OUs, custom fields and such.
The movement of implementing a new technology and pushing everyone to change everything around is just proof of a company that does not care about the long-term customers.
For user identities, those on-prem characteristics still exist if you use hybrid users, even without hybrid devices.
I guess if the DC is joined with AAD and the users are being replicated back to the On prem AD then I see why it allows straight through,
I will test this myself and see
But I agree that On premises resources are very complicated to troubleshoot and seem to be phasing out .
The user accounts just need to be synchronised to Entra ID / AAD for them to be able to log into a cloud only (AADJ / Entra ID joined) device.
Great video. I planning on moving my file server with a sql database on same server from on-prem environment to Azure. Do I also need to move my domain controller to cloud? Then do i use Azure Ad join machines only or do I use Hybrid AD Join. I just need some direction on how to proceed. I want be able to access my network shares from cloud only. This will only be cloud solution.
This video shows how you can access file shares hosted on-prem from Cloud Only computers. The computers still need network access to the file share, so any solution will always need you to either have the computers in the same network location, or be accessible by some routed network or VPN.
In your case, placing the fileshare in Azure won’t mean that Cloud Only devices can access it. The location of the file share is not the factor that determines this, as you need to ensure that the computers can access it anyway.
If you’re moving the fileshare to Azure for other reasons - such as downsizing your own hosting perhaps - then that’s fine. Just be aware that you’re not solving the access problem, you’re just changing it.
Do I still need a domain controller in azure or can I just use azure AD to Join cloud based computers and still have access to azure file server shares
A domain controller in hosted in Azure is no different from a domain controller hosted on-premises, from that perspective. Use Azure AD.
I assume you mean Windows Server Fileshares hosted in an Azure VM (as opposed to Azure Files).
Perhaps this video will also help? ua-cam.com/video/66I2P6XjTyY/v-deo.html&lc=UgwOs8-91APY4ywQbcV4AaABAg
I have 2 thoughts regarding this.
The first user I think/suspect that he/she have there credentials stored on credential manager (becuase u did type it in once before) and thats the reason Windows is not asking about login and password.
The second user Mr. Jester not sure... It might be as we dont really se all of the NTFS permission there might be the account "users" left and that might be a reason for access ?
If the upn and the password are the same it might be "the XP expersience " all ower again.
Every one signing in with Adminsitrator and not having a password on the account so windows just saw the same Login and Password and let everybody straight in other system that hade the same poor setup.
Sure, I get it but why all the hoopla around Hybrid join? Even watched a video where you gave instructions on how to do it. Sure GPO is different but not quite there in Intune really (it supports like 4-5K of policies out of the 8K+ available policies - unless you use policypak), I'm in an architecture firm the apps we run are can be up to 15-20 GB - etc... there are advantages of having domain join surely? Intune/MEM just doesn't cut it yet as a total solution - which is why we are co-managed. So if we go Autopilot for provisioning our new hardware, there is NO need to have them domain joined? Am I missing something here?
Thanks Nazid,
Why am I against Hybrid AD join? Firstly, password resets are a pain, as are forgotten passwords. The device must be in the office or connected to a Device VPN to use the user's new password.
Aside from that, you're right - there many cases where Hybrid Devices are required. GPO is a great example.
This video is not aimed at those engineers, architects or organisations that have thoroughly evaluated whether Azure AD will work for them. It is aimed at the 95% of organisations that assume Azure AD can't do X, where X is file-shares, printers, web-apps.
Aside from some niche GPOs (or a large number of niche GPOs), I (personally) don't believe there are any advantages of Domain Join over Azure AD Join. If there are, in your view, I'd love to discuss them.
We're all learning here, and I appreciate the comment.
/Dean
Good thought, but doesnt really work well, for example i cant even install vpn
If 100% of your user accounts are not synced to Azure through the AD connector, then you need to domain join. We don't upload any of our admin accounts with special privileges. So anyone with an admin account with special access or privelages MUST be on a domain joined device. Otherwise the user can't authenticate at all.
Sounds sensible. So you could cloud join all devices except the admin devices?
what are the benefits of this?
until you realize your main computer used to manage your servers is azure joined and now you have no way of using admintools to manage the server.
But how did you do it?
Do.... what?
So how does it work…?
This video explains a little about how you should configure this with the latest capabilities:
Hybrid cloud Kerberos trust deployment - Say NO to Hybrid Azure AD Join!!
ua-cam.com/video/66I2P6XjTyY/v-deo.html
This doesn’t work if you’re using applications which use the computer account to access resources, such as Hyper-V. For example, I cannot access ISOs on a network share unless the system account can access that share which would require a domain joined account :(
Very true! There are some clear reasons where Domain Join is required. The idea of the video was to challenge the default mindset when moving to Intune managed - hybrid is not required… until it is.
And the question is: why? Azure AD is not aware of your corp\account is it?
It depends. This video was about not hybrid joining devices.
You should probably still have on-premises users and sync them to the cloud. That’s a good idea.
But let those users (with synced credentials) use cloud only devices.
They can still access on-premises file shares and apps using their on-premises credentials.
You do need to join to pick up your group policies though... :(
Indeed. Just don’t use GPO :-)
I do not agree. Of course you domain join your client devices, to save time and resources. Why else would you keep a domain locally?
Domain Join doesn’t always save time and resources when compared to Azure AD Join.
It does not work in a Hybrid setup for users in OOE mode outside the on-prem network. The above video will work in a VM Lab setup where there is a line of sight of on-prem resources. For Users in OOE setup at home, in order to access the on prem resources, they will need their PCs to be domain joined via VPN.
I'm not sure if you were being coy but when you acted surprised it logged you in without prompting for creds, it didn't inspire confidence you knew what you were talking about. That being said, I am inspired to learn more. Thanks!
Thanks.
No, that was genuine surprise. As is the theme of most of my videos, I’m not an expert in all areas that I cover, and am learning as I work through some of the specific areas that I think people might be interested in.
I had expected the device to prompt for credentials as I had not enabled SSO in Azure AD connect (as did some of the others watching and commenting on this).
My plan was to have the prompt appear, then explain that I would need to enable SSO to get it to be seamless…. It turns out that it actually does just work, even without SSO enabled.
I’ll be doing a video shortly where we we break down how that all works, now that I’ve looked into it :-)
@@theCMC awesome. This is my first video of yours and I'll plan on watching more. Thanks
On-premises, not on-premise...
noted :-)
/Dean
I fixed this in my latest video on this topic 🙂