Can I use the Azure AD DS to manage on-premise machines?

Question

question

TuvshinjargalBatsaikhan-3519 asked Dec 5, '19 EastCoastEh-1629 commented Mar 10, '21

Can I use the Azure AD DS to manage on-premise machines?

We are using office 365. Also, Using Azure AD of Office 365 for identity. Now, we are intending to manage and secure our workstations using GPO. So, Can we use Azure AD DS for this case.
We don't want to manage on-premise AD DS. Just want to use the cloud services for identity and management of on-premise windows workstation and servers. The reason to choose the Azure AD DS is we are using LDAP, kerberos. I think we can use Azure AD DS for identity through site to site VPN connection and management of on-premise workstations in on premise site.
Also, We don't have any on-premise AD DS. But our users, groups and devices registration are on Azure AD of Office 365. How to solve the problem? As I referenced, to manage on premise windows machines, I must use the on-premise AD DS. Can I migrate existing users, groups and devices information on the Azure AD to on-premise AD DS?

azure-ad-domain-services

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Answer 1 · 2019-12-05T05:36:27.957Z

amanpreetsingh-msft answered Dec 5, '19 TuvshinjargalBatsaikhan-3519 commented Dec 9, '19

@TuvshinjargalBatsaikhan-3519
Yes, you can use Azure ADDS to manage your on-premise workstations provided you have a Site-to-Site VPN connection between on-prem and Azure. Users and groups created in Azure AD are by default synced to Azure ADDS. You can use Azure ADDS to manage and control workstations using GPOs as well. Please refer to https://docs.microsoft.com/en-us/azure/active-directory-domain-services/manage-group-policy for more details.

The only challenge I see in this scenario is, if the site-to-site VPN is down, your workstations will not be able to communicate with Azure ADDS Domain Controllers.

Migration of existing users information on the Azure AD to on-premise AD DS is not supported. Using AD Connect, you can preform Group and Device writeback but users cannot be synced from Azure AD to On-prem AD. As a workaround, you may consider deploying Azure ADDS and once the objects are synced from Azure AD to Azure ADDS, export the users using LDIFDE as mentioned here and import it to On-prem AD. Hope this covers all your questions.

Please "mark as answer" or "vote as helpful" wherever the information provided helps you to help others in the community.

· 1

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

TuvshinjargalBatsaikhan-3519 · Dec 09, 2019 at 07:14 AM

Thank you. @amanpreetsingh-msft
It is accurate answer for my question.

0 ·

Answer 2 · 2019-12-05T05:27:03.623Z

BijuThankappan-5910 answered Dec 5, '19

Since you intend to manage and secure your workstations using GPO, you should be able to do it provided all the onprem workstations are joined to Azure ADDS via proper vpn/network channel.
However, please be mindful that as of this writing, Azure ADDS is more like a supplement/BCDR to the onprem ADDS and still has some more room to accommodate to take on the entire gamut of facilities onprem adds offers.
Refer this article for latest comparisons. Refer this article for how to manage GPO in Azure ADDS.

Please take a moment to "Mark as Answer" and/or "Vote as Helpful" wherever applicable. Thanks!

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Answer 3 · 2021-03-10T16:05:35.307Z

EastCoastEh-1629 answered Mar 10, '21 EastCoastEh-1629 commented Mar 10, '21

I'm writing to follow-up if the original poster had scucess with this? We are in the exact same situation and I'm hoping for some feedback.

we have zero on-prem AD. As you can imagine this creates a huge headache because we are basically individually managing endpoints, and users have to have local accounts on their desktops (or a bunch of desktops if they use more than one computer...shared accounts sometimes for shared computers) and then those usernames/passwords have to match the local accounts we use for permissions on the file share servers we run. It worked when we were small (before my time) and now it's unmanageable.
On top of that, we have Office365 which we've been leveraging for email/word/excel, etc., so that's another username/password to manage.

Azure AD is what sits on the back of Office365. When you create a user in Office365, their account is setup in Azure AD.

We also recently stood up Azure AD Domain Services, which is setup as part of the infrastructure of some Apps we have running in Azure that required AD.
Consequently, the VMs which those apps are running on are joined to the Azure AD Domain Services domain. The Azure AD Domain Services is 1-way synched with Azure AD.
This all basically just allows our users to use their Office365 credentials to connect/authenticate to the VMs and apps we have hosted in Azure. That part works nice.

So since we have Azure AD Domain Services running, and it's synched to our AzureAD/Office365 credentials, then my thought was why not simplify our on-prem life and make use of this?
We can connect our on-prem devices to Azure AD Domain Services by extending the Azure AD Domain Services over site-to-site VPN to Azure we have setup.
The big win is our users will then get down to a single username/password that will work across all domain devices as well as when they access office365 or the Azure hosted appswe have.
For new users we only need to create the username/password in Office365/AzureAD, which will then synch over to Azure AD Domain Services. (Existing users we had to force a password change to get that synch to fire) If our users need to move between shared PCs they can do that easily because it's a domain and your acocunt works on any domain PC. And we can use Azure AD Domain Services for other ldap type queries we may need on-prem for some legacy apps that we've always had to create separate accounts for..e.g. sslVPN).

I've already tested this and its working fine. The reason I wanted to add an on-prem DC to the mix was just in case our internet goes down we'd be dead in the water in terms of accessing anything on-prem that required AD (e.g if we built our on-prem fileserver around AD users and groups).

· 1

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

EastCoastEh-1629 · Mar 10, 2021 at 07:35 PM

An issue wth having no on-prem AD would be increased traffice and sensitivity to latency that could occur? I'm thinking file shares for a server on prem may be slower to access if the auths are constantly going out to the cloud?

0 ·

question