Automatic device registration happens despite GPO control. Disabled doesn't work #31078
Comments
|
@TechTrooper Thanks for the question! We will investigate this issue and get back to you soon. |
|
@TechTrooper can you please confirm the value of the "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin" registry key on the machines where you applied the Group policy ? |
autoWorkplaceJoin value is 0 with the GPO: "Register domain joined computers as devices." set to Disabled Here's the device state after setting up SCP for Azure AD Hybrid Join. GPO to disable registration is still applied and registry key exists, but it's ineffective. This can be disastrous for organizations expecting to perform limited registration. |
|
@TechTrooper I have reached out to the Product group regarding this and they are working on fixing this in the next update. Currently the suggested workaround for this to
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD] This registry will help the device identify which tenant to target for the device registration. I understand this is not the ideal solution, the product team is working on this and the document will be updated with the changes as well. Hope this helps. |
|
@TechTrooper We have not heard from you in a while.We will now proceed to close this thread. If you have further questions, please tag me in the comments and I will gladly continue the conversation. |
|
@ManojReddy-MSFT, |
|
Hello, |
|
@ManojReddy-MSFT, |
|
We've just fallen foul of this issue, why has this been feedback been closed without updating the documentation to alert people the GPO control doesn't work?! |
|
@lightupdifire Generally Device registration task runs on every Windows 10 device automatically and having the GPO described int he doc will prevent his task from running. In a federated scenario, when you configure AAD HJ through AD connect, ADFS rules are created and updated by AAD Connect, so if the rules are created correctly then the device will be joined to Azure AD. I am not sure what you mean by "select only down-level via AAD Connect", can you post a screenshot of the setting? @benzini00 I am sorry for the inconvinience caused by this. I was informed that the product team is making the appropriate changes and hence I clsoed the issue. I followed up with the team today and will provide an update based on that. |
|
@ManojReddy-MSFT Question is, if using this 2nd option only, any similar issue like this case we could face? |
|
@lightupdifire The ADFS claim rules required will be created when you select either of the options. So, your Windows 10 devices also will get registered if you have any in your environment. You would have to follow the steps mentioned in this doc and clear the SCP and use a GPO to populate the required registry keys. @benzini00 The article has been updated with the information regarding SCP. let me know if you would like us to include any other details. |
|
@ManojReddy-MSFT, What should be done to Disable automatic registration for Windows current devices for Managed domain? What should be done to Disable automatic registration for Windows current devices for Federated domain? Regards Regards: Regards: And if not using Configuration Manager? Just get really confused what should I do now to STOP automatic registration for any deployment scenario I choose.. And if I choose Managed domain or Federated domain, what exactly should be done, is it possible describe step by step and not like "look above" and "look below"? Old article was more clear in terms of document setup, reading that could better understand like to stop all devices auto-register i need: 1-2-3 Now is like only giving option what to enable to do automatic registration, but not really explaining what to do to stop it... |
|
@lightupdifire Here is all that you need to do:
|
|
So if we have:
Our plan is to use only "Down-level" solution now. Our action would be:
All those steps would be correct? |
|
@lightupdifire You would also need to create the SCP on the client using client-side registry option. Windows 10 and Windows 2016 will not be auto-registered. Yes, the task which is running on these devices will look for SCP and as it is cleared, auto-register will not succeed. |
|
@lightupdifire We have not heard from you in a while. We will now proceed to close this thread. If you have further questions, please tag me in the comments and I will gladly continue the conversation. |
|
@ManojReddy-MSFT [Option1] [Option2] |
|
@ManojReddy-MSFT 2 weeks ago I did open a ProSupport ticket via Azure and they confirm to me, that Product team confirms following issue:
So for us will be important to block any "Current version" devices, because "Down level" devices require an agent installation at least. Can you please advise, what will be best roll-back plan in scenario:
How to make those devices that do auto AADHJ to be just only on-premise domain joined as they were before and stop auto process? |
|
@nielsvdGH Removing the SCP and pushing the SCP GPO only to the devices that need to be registered to Azure is the recommended solution. Removing the devices from sync scope will work with a managed domain. It will not work when you federate the domain. In federated scenarios, device authentication happens at the ADFS level and does not need synchronization. @lightupdifire Yes, all versions will be affected when you enable device registration irrespective of the AD Connect setting. Removing the SCP is the most important thing, as the automatic device registration task will look for it and when it does not find the SCP, the device will not be able to join. Once the SCP GPO is pushed, the registry key will provide the details required and the process will continue. In a scenario, where you have windows 10 devices registered to Azure and you want to remove them, you need to do the following:
Hope this clarifies things. |
|
@ManojReddy-MSFT Just checked production domain and can't find "azureADId and azureADName" |
|
@lightupdifire AD connect configuration has a step in which SCP is configured. So after running AD connect SCP will be created. You can validate this by running the following command and remove it if it exists. $scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=fabrikam,DC=com"; $scp.Keywords;"
|
|
So seems like it is not possible to prepare environment to block auto registration without running ADConnect wizard, is it so? So maybe steps should be re-ordered for "Controlled validation of hybrid Azure AD join on Windows current devices", something like:
|
|
That is the main question from me, how exactly stop auto-register. So I think best will be to do:
|
|
Because we don't need any other device or any auto-register process to be done at all, only few required "Down level" devices, Do you confirm that the best steps, to stop auto-register, will be by doing this setup in following order:
|
|
And btw. did anyone tested by doing:
? |
|
Hope you are doing fine, if possible, please would be great to have comment on last 2x questions. |
|
@lightupdifire Apologies for the delay. The action plan you have looks good. Updating AD Connect will not affect the SCP configuration unless you rerun the configuration wizard. |
|
Thanks, we plan deployment this/next week and want to make sure, that we really can stop Hybrid Azure AD join, after configuration wizard completed, |
|
@lightupdifire Sure. I am looking forward to hearing back from you. |
|
We run deployment, in result:
So in summary, I think "Controlled" process not very well running, |
|
After troubleshooting found following:
In summary, controlled worked well, but I would advise maybe to add in doc, to run script to clear records and make script loop continuously while run wizard. Thanks for helping out! Have a great all ahead ;) |
|
@lightupdifire |
|
I too am confused by this article and have been far more enlightened by this comment thread than the article itself. Suggestion: Please update the article with any relevant information shared in this thread. People should be able to read the article and get what they need in terms of configuration steps. Question @SanDeo-MSFT , @ManojReddy-MSFT : I am working on a controlled Hybrid Join deployment in our managed (pass-hash) environment of win10 computers. I'm still not totally clear on the steps, so please verify or correct what I have listed below:
After completing the steps above, any clients that have SCP configured should begin to hybrid join, correct? Thanks |
|
@JoelHazelton Apologies for the delayed response. Your action plan looks good. Only devices with SCP configured on the client-side will be joined to Azure AD. I will work with the author to enhance the doc. |
|
@JoelHazelton Sharing my experience when we run Hybrid AAD Join for ADFS solution:
If critical for you, then monitoring and clearing SCP should be done quick, we saw some devices start register very quick, we got ~5 devices in ~10 sec while we cleared SCP. |
|
I'd love to hear a comment from Microsoft when this might be fixed. Does it require an update of all Windows 10 devices to a new version for example? Even though we have a work around, it's not pretty. |
|
Hello, It's now 2020 and all of the useful information resides under this 'closed' feedback topic, which I find very annoying. If device registration GPO doesn't work and you're suggesting that clearing the device registration SCP from Active Directory and using the ClientSideSCP Method is the only way to achieve a controlled rollout, could you please remove the below article, as it was the the first result on Google when I typed "Controlled roll out of Hybrid AD" - If you could also update this article with any relevant information that would be great. Too much conflicting information which is clearly confusing everyone! |
|
Also, is there any ETA on when the device registration GPO will be working again? As I say, there is conflicting information on the internet regarding this topic and it would be good understand if this is still an issue or not. |
|
I fully agree with @jakeives95. I have learned far more from this thread than from the documentation. Both this this article and "Configure hybrid Azure AD join for federated domains" needs to be more clear around which options to use when. Didn't even know about the third article @jakeives95 he just linked to. I will ignore that one considering it has not been edited since 2018. We just started a controlled rollout thinking that the steps in this guide would be enough. However, what this guide fails to include is the fact that AD FS also needs claim rules configured - and not only to the SCP as referred to under "Configure AD FS settings". Please update this article to notify people that AD FS claim rules will need to be configured via AAD Connect or manually for a fully supported join. I know that some devices will registered without the claim rules due to the fallback option, but the fact that this information is left out resulted in a full day of troubleshooting and a delayed rollout. Some devices manage to use the fallback and other don't, so this articles is not applicable for AD FS environments unless claim rules are configured in advance. There are also other prerequisites about proxy etc. that this article leaves out. I would even advise to migrate this article it to "Configure hybrid Azure AD join for federated domains" and "Configure hybrid Azure AD join for managed domains" - then remove it. Otherwise it needs to be updated to include all the details discussed in this thread. For example, add a section under the other tutorials for "Follow these steps to enable a per-device enrollment via GPO" and make it clear that the option would be to auto-join everything outside of your control. Then include the incredibly important step from @SanDeo-MSFT at 1 August 2019, about skipping the SCP configuration in the AAD Connect Wizard. |
|
It is now 2022 and the GPO to prevent Auto Azure AD Join still does not work. Moreover, when you are on a restricted network that does not have full internet access, you login is slowed down by 2 minutes. It has to time out trying to connect to azure before falling back to local authentication on Azure AD joined machines. If I run dsregcmd /leave, the machine still get re-joined to Azure AD after some time. This is despite having the registry to BlockAADWorkplaceJoin in place |
At the moment GPO "Windows Components/Device Registration/Register domain joined computers as devices" has absolutely no effect. Disabled setting doesn't block Windows10 Azure AD Hybrid Join.
Once you install ServiceConnectionPoint for Azure AD Hybrid Join, every single Windows 10 machine in forest will perform AAD Hybrid Join. Doesn't matter if OU's are synced or not in AAD Connect.
Also happens in child or tree domains, they don't have to be even verified to AAD.
W10 devices get enrolled as AAD Hybrid Joined anyway.
Tested on Server 2016 with federated root domain and Windows 10 1803+1809 client VMs.
This can be huge issue for several of our customers and can delay purchasing M365 licenses until fixed.
For many organizations it is not a realistic possibility to join every W10 device in a forest to AAD
Here's comments from someone else who noticed same problem and apparently Microsoft support has replied that it's a known issue..
https://community.spiceworks.com/topic/2203360-devices-hybrid-azure-ad-joining-despite-gpo-applied-to-block-it
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: