Hybrid cloud Kerberos trust deployment - Say NO to Hybrid Azure AD Join!!
HTML-код
- Опубликовано: 8 ноя 2022
- 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-premises resources. It's not a requirement, and it's not a good idea.
#SayNoToHAADJ
Want more? Dean's full Intune for Windows course has you covered. Here's an exclusive RUclips discount: www.udemy.com/course/learn-in...
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. Наука
I'm a lazy admin, so all my sources are from Microsoft!
Here's how to set up Azure AD Kerberos:
learn.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module?WT.mc_id=EM-MVP-5004668
And here's how to set up Hybrid cloud Kerberos trust:
learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust?tabs=intune#deployment-steps?WT.mc_id=EM-MVP-5004668
cheers
This works great except for SQL Server Reporting Services. I get pop-ups only on that application. I am guessing because it does not understand modern authentication?
Brilliant, got to test this. Would get rid of alot of obstacles. Thank you.
thank you very much for your great knowledge nuggets!
I have just implemented this for a client and just thought I would note a possible "Gotcha" around the creation of the Kerbros server in regard to privileged Accounts, not that its "best practise" to do that. But if you have a user who has a privileged role eg Domain Admins , Account operators, the Kerboros object wont allow the PIN to work.
For this, you will either have to remove the privilege role from the user or modify the Password Replication policy on the server object.
Darren
Great video, thankyou. I have a question about accessing on-premises file shares. I assume access to files still uses a token generated at login that is used by the SAM on the target file server to compare SIDs in the token versus those on the access control lists of the target folder? Has this process changed at all? Does the token include a new SID for the Azure AD user object and the historical SID associated with the On-Premises user object \ groups etc?
What's the experience for users who are already AAD joined and setup windows hello on their computer, but now you've introduced the kerberos trust via the configurations here for both hybrid join and AAD only devices? Will their PIN/biometric now start to work this way, or do you have to do something to re-enroll them now to Hello for Business vs just a standard Windows Hello?
This seems to work. What about using RDP to on-prem servers? It prompts for pin, even though it doesn't work.
So, you have to use a domain admin and global admin user name and password to set this up? What about passwordless with a domain admin using smartcard authentication and global admin using the authenticator app or FIDO2 key for login?
Great video, and thank you for the resilience on hashing out these discussions with everyone.
I'd like to ask your opinion on existing devices though. After seeing this video, I certainly believe that is an ideal state to put net-new devices in for environments where things such as SMB file shares are still required. For existing devices though, from what I can tell, moving an AD-only joined machine and a hybrid joined machine to a cloud-only state are nearly the same process. If that is true, would it make sense to move existing devices to a hybrid state, and new devices to a cloud-only state?
Great video, I've had problems since starting to switch clients to Azure from onprem. Can you make a list of your powershell commands available please.
Good point! Sure will
why does it require to setup cloud Kerberos trust if the intention to access on-prem file shares via Kerberos? directory synced account on a Azure joined machine will get Kerberos token anyways if it has connectivity to the domain controllers!
I cant find any info on this in the documentation, but using this setup and signing in to an AAD joined device, is it required to ALWAYS have a connection to BOTH Azure AD and On-Prem AD, to be able to get a full Kerberos ticket?
Or is there some kind of cache for the partial TGT from a previous sign-in, that the device can exchange for a full TGT in case there is a connection to On-Prem, but Azure AD is down/unavailable for some reason?
Great question. I’m going to guess that a connection to on-prem AD is not required for the ticket granting, but AAD is vital.
So can I clarify a couple of things?
1) Was the new machine setup done while on your corp network, or can it be on any network to perform the Azure Join, I know the Azure Join can be done from any network connection, but thought I'd still clarify.
2) After Azure Join the machine, I noticed that you were able to access your corporate DC, does the machine on the same need to be on the same network as the DC, or does the Kerberos Auth that you performed earlier acts as tunnel?
New device to be on the same network.
The device can be configured on any network, yes. It doesn’t need line of sight to a DC for provisioning.
The device does need network access to the resource it’s trying to access; either by being in the same network location, via VPN, or the app being made available in some other way.
Does this require AD connect?
Why do you assign a device policy on All users?
intune requires any on premise access drive mapping, printer access, vpn etc how to implement requires network connection configuration from on premise network to Azure network?
Great video👍🏻. Quick question though regarding setting up Kerberos object. What would be the domain if i am running this on a server which is part of child domain and not root domain. Also the domain credentials, do they require Domain admin only or Both Domain admin+ enterprise Admin?
The "domain" used in the set-azureadkerberosserver command is the on-prem AD domain where your user accounts live. The domain credentials need to be a domain administrator in that same domain. The system from which that command is run needs to exist in the same AD forest.
Hi there, how do I Set the AzureADKerberosServer object in my onpremise AD if i have different AD DNS names? my AD DNS name is internal and different to my Tenant one!
Thanks for this video.. This is really good.. Can you please share the link to the other video which you made saying No to Hybrid Domain Join..!!
Got it.. Found that in comments :)
I know this is an older video but I have been studying up on this technique for some time now. If you configure that policy and apply it to hybrid devices, does that negate the need to configure it also in group policy on the local AD?
If the devices are managed with Intune yes, if they are managed with Configuration Manager you will need to configure it there or via GPO or set Configuration Manager to allow the specific devices to be managed via Intune.
@@kennethlindgren856 Thanks!
Please explain me what is Cloud Kerberos trust deployment and is this by default on my Windows 10 or was this installed with a software installer ?
It have made me a bluescreen.
It certainly simplifies things. The only concern would be that if a user wanted to find out who had access to a share would it enumerate to users name or account guid?
The users are on-prem users, so it would show the username.
Meaning AD connect will exist in the environment?
Hi thanks for the video! I can't seemed to access my on-prem file share with a synced hybrid AAD account on a Azure AD Joined devices. My klist is empty and it shows I have no permission to access the file share(I have given permission to the on-prem synced account). Can you show me how did you configure your file share or what could be the issue? Thanks!
The fileshare was configured in a very simple way. I don’t think the server side will be your issue.
Enabling Kerberos Cloud Trust Hybrid - How does it effect an existing tenant of users/computers? If i just want to test WHFB on a few devices is this possible or are there implications once kerberos cloud trust hybrid is enabled? Cheers for any advice.
No impact to the experience of the users, but you will note that the output of "dsregcmd /status" will start showing "OnPremTGT: Yes".
Prerequisites for this to work, along with unsupported scenarios are shown at this link: learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust?tabs=intune#prerequisites
Hi
Nice video, I would like to inquire about we have 2012 R2 DC along with Server 2019. Does WHFB-Cloud Kerberos Trust model compatible for Server 2012R2.
Server 2012R2 is out of support and Cloud Kerberos Trust is not compatible with that version of the OS. You must have at least one Server 2016 or newer DCs in each AD site where users will authenticate.
The average user wouldn't know how to manually get to the fileshares - which is why we've been mapping them via scripts and GPO's for them for over 30 years. They'd be calling us all day trying to find their files :)
Hi!
I wonder if you are in the same network or using vpn to access shared files or did you I miss something here? Can you clarify please?
I was on the same network. I had line of sight to the fileshare.
The trick is not about accessing remotely, it’s about accessing without a domain joined device.
Dean will this work for existing AutoPiloted devices in my environment? That do not have Hybrid cloud Kerberos trust setup yet.I have about 500 autopiloted devices who want to access on-premises resources?
Yep, should work. Catch me on LinkedIn if you need help. /Dean
@@theCMC Well I am just testing this in my test lab before I try in my environment and I have an autopiloted machine and when i do a klist i have 0 cached. Everything else is setup correctly per your video
@@clivebuckwheat, if this device is EntraID joined, you won't have any kerberos tickets showing until you attempt to access a kerberos resource. Check the output of "dsregcmd /status" and make sure "OnPremTGT: Yes" is showing. Then you can attempt to accesss an on-prem file resource and verify it is working there. I use the sysvol file share that exists on all AD domain controllers. Something like "dir \\onPremDomain.Name.here\sysvol" will trigger an attempted Kerberos auth.
I set this up in my home lab and it appears to be working but when I run klist it says there are no cached tickets.
You might missed configuring the Kerberos ticket server as per the guide that he posted above in the comment section :)
I realize it's outside the scope of the video, but how did you configure the custom branding you can see at 8:10?
I cover it in this video: ruclips.net/video/t6RLxsGCM6A/видео.html
Was amped to finally set this up until I realized our Domain Controller's are too old. Need to upgrade.
Aw man! Atleast you have a good reason to upgrade now!
@@theCMC Yeah we have to upgrade all of our 2012 R2 servers this year.
@@breakingcustombc2925 you aren't the only one, I have a bunch to upgrade as well. At least the File Server Migration wizard looks pretty good now ;)
@@OldFellaDave Yeah I heard some good things about the new wizard. My biggest issue is going to be legacy shit that was installed before I came on board (Flexnet, etc).
hi, this is working great...but not for all users. They are not special in any way that I can see. Any tips on how to troubleshoot them?
It is important to define what "not working" acatually means. If we assume that these users are able to enroll in the credential and the issue is with using the credential with on-prem resoruces, the best troubleshooting tool is a network trace. Take a look at the Kerberos traffic and, specifically, the response from the domain controller.
Got this sorted out. Certificate issue. Thanks for you reply :-)@@jjstreicher-bremer309
Where is the original say no to hybrid video? I could not find it from searching...
I added it as a card at the top right, but it's easy to miss and might not appear on the platform you're using. My bad.
here it is :-)
ruclips.net/video/4R-krjqQKfE/видео.html
@@theCMC Thank you, just me being a tad blind :)
What if they're using a VPN to access their on-premise resources?
This will work fine, as long as the VPN is not requiring a certificate for authentication. User-based authentication will work fine.
Best practice is to rotate the Kerberos key every 30 days. Have you been able to automate rotation through an Azure automation runbook?
No need
Do you have a video which is more designed for absoute beginners? This all feels a bit rushed and designed for people who are more familar with the products than I am? :)
A video about Intune, or Hybrid Cloud Kerberos Trust?
@@theCMC cloud trust and or windows hello.
This is not true.
You could only access you on-prem resources because your Azure AD joined device and your DC were on the same subnet.
Try accessing your on-prem resources when your DC and AADJ on different networks.
Well… not necessarily in the same subnet, but accessible in the network. It’s required to actually be able to access the network location of the resources. That can be solved by either being in the same network location connected by switches, or via a VPN, or via any other method that gives network access.
The point of the video wasn’t that Cloud Only devices can magically defy networking constraints.
How would you propose getting access to on-premise resources while not connected in some way to the on-premise environment?
@@leastmachine8693 Through AD Connect, I guess...
I thought that was the whole magic 🤦🏻♂️
Hello Sir , line of sight to a DC