Support Azure AD domain join for Windows Server 2016
Microsoft should strongly consider implementing support for Azure AD join in future builds of Windows Server 2016. I how a couple of customers that have nearly finished the transition to all cloud and is left with a couple of servers due to legacy software. They are currently left with the option to deploy Azure AD Domain Services for supporting a couple (2-5) servers.
Peter Selch Dahl
shared this idea
Currently, we are not aware of any plans from Windows Server for this capability. We’ll continue to work with Windows Server to revisit this in the near future
27 comments
-
Niklas Riddarlo
commented
We need this!!!
-
Matteo Lo Piccolo
commented
Unplanned.... wow.... just.. why do you want us to still use an on-prem AD... its unnecessary and AD connect is really a bad idea.. come on..
-
Anonymous
commented
Needed, Full AD should not be a requirement for RDS.
-
Anonymous
commented
Needed
-
TM
commented
This should absolutely be on the roadmap for Windows Server 2019
-
Thomas Baklund
commented
This is really needed. The servers use AADDS today and it has a few limitations. If the servers and WVD could just join AAD as regulers W10 does and we could eliminiate the need of an AD DS server with the users it would help us a lot.
Login to app servers/RDS could be done using the already logon hello credentials
Guest users from trusted organisations wich use same ERP system but is in a different tenant can use their own credentials an Guest user to access instead of having to get a second account in correct domain wich leavs a lot of confusion. -
L
commented
This is terrible. Why is it in Windows 10 and not Server 2019!?
-
SS
commented
I agree, for SME who want to go cloud only, it would be ideal if we could just migrate the LOB apps to Azure VM servers and just join to Azure AD....saves an awful lot of work and costs to the clients..
I am also PoC a Hybrid Azure AD join RDSH server scenario, so I can test Conditional Access against users sessions initiating from a Hybrid joined RDSH device.
We have a test tenant with public FQDN and routable. I have followed all MS documentation, setup AADConnect, SSO, SCP, GPOs followed it to the letter, but for some reason the device ID does not appear in Azure for the auto join to occur!
I tried Winodws Server 2012 R2 (with workplace client), 2016 DC and 2019 DC versions, none of them I can Hybrid join to Azure AD...
it would have been ideal if like Windows 10 there was an option to Join to Azure AD from settings>accounts, rather than going through all this work...
-
Anonymous
commented
windows 10 - Azure AD.
Server 2019 - no Azure AD?
C'mon, help us embrace SaaS, while making you some money in the process. Forget On-Prem AD. -
Anonymous
commented
+1
-
Anonymous
commented
+1!!
-
Christopher Neufeld
commented
In an increasingly cloud-centric environment, this is a must-have. We run a slew of servers across various cloud services and it would be extremely beneficial to be able to centralize and manage logins using Azure AD.
-
Neil G.
commented
In case its not clear - this is a request for windows server to be able to register as a known device to Azure AD -- NOT Hybrid join -- with the short term goal of being able to login with our Office 365/AzureAD identities as well as local "break the glass" login.
Probably long term goal would be MDM server management through Intune but that is a whole different request.
-
Larry Gonzalez
commented
Is there any update about this feature?
The "Under Review" is from March 1, 2018 -
HenrikE
commented
This is needed. The comment below shows that Microsoft don't even understand the question. We want to be able to join server OS directly to AAD, just as we do clients. While this may mean that the server OS will need to be able to consume an OAUTH token, it is most desirable to be able to remove the onprem AD altogether while keeping the option to deploy the occational member server.
-
Jeff
commented
Any Update ?? For Support on 2019.
-
Gerald Talton
commented
Hey Ravi, this "Under Review" comment is almost a year old, can you give us any insight on where this is on the roadmap?
-
Gerald Talton
commented
Without this feature, my attempts to integrate with my employer's current Azure AD. Currently I am being told that installing Azure AD DS is not an acceptable security risk and that this is the only way they would consider supporting AD access.
-
Josh Aitken
commented
We are rapidly migrating traditionally on-prem SMB's into the cloud and one of the primary issues we run into is the inability to shift clients on-prem LOB's into Azure VMs without also dragging the unwanted, typically poorly maintained onprem AD's along with them.
AzureAD connect/ ADFS does not fulfill this request, the benefit of the cloud is we can reduce cost/ complexity and general administrative overhead - the aforementioned technologies do the opposite (at least with respects to SMB's).
-
Tom Hebert
commented
@BenTheBuilder is spot on. For large organizations, maintaining AD is fine. But for many others, it's overkill. Imagine the scenario where you are supporting a small business having two servers. In order to use AD, you need to maintain an AD server and best practice says two. AD domains are fragile and must be carefully operated or you will be finding yourself researching and fixing very complex issues.
This hypothetical business really wants single sign on, two-factor authorization, and some basic things. Their one and only admin has full control anyway. Pushing complex group policies is just an unnecessary complication. Most other things associated with AD are an unnecessary costly distraction.
Finally, a simplified on-premise environment is much easier to move to Azure. When I do this, the first thing I do is provision a replicate domain server in Azure, mainly to ensure that authentication can occur should the site-to-site VPN go down.