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.
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
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..
Needed, Full AD should not be a requirement for RDS.
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.
This is terrible. Why is it in Windows 10 and not Server 2019!?
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...
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.
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
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.
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.