Can I join an Azure VM server to MS 365, then promote it to a Domain Controller so I can connect a local resource to the directory using LDAP?

Question

Hello,
I have a customer with an MS 365 account. This account has 40 users in it. 25 of those users work outside of the company's Main Office. The other 15 are administrative and support personnel who use a Windows 2012 R2 Business Essential server to sign into the network.

The 25 outside users have devices joined to their MS 365 tenant and access it using their email address and password. The 15 users in the Main Office sign into the network using their credentials stored in 2012 BE, then access their MS 365 resources using the email address and password. By design, BE never syncs with MS 365 so we have a situation where user ID's and password are not synched (unless done so manually by the end user).

The 2012 R2 server is starting to show its age and the customer wants to shut it down and have MS 365 handle the user security. However, the local office has some resources that are tied into the Directory Service on BE that do not convey to MS 365. To address this, the customer purchased a 'Smart' NAS appliance. This appliance has a LDAP tie-in allowing it to mine an LDAP service, pull in the user accounts, with the end goal being single sign-on for resources both locally and on MS 365.

Well, I need an IP address to connect the LDAP feature to MS365 which isn't available by default. So, the customer authorized me to use their Azure Trial account to see if I could create a virtual network so I could make that connection. Well I went so far as to create a Virtual Network, a Virtual Network Gateway, a Site-to-Site VPN link between Azure and the Main Office, a Win 2019 Virtual Server, a Public IP address to connect to the Azure gateway, and a NIC on the VM to run an RDS session. When I tried to join this VM to the MS 365 network, the internal DNS could not resolve the domain name. Even tried using the fully realized onmicrosoft.com version of it, but no luck.

So, Is there a way to pull the MS365 security account database over the VPN into a non-Microsoft device so that the same user IDs and password can be used to access resources both locally and on MS 365?

Thank you very much for your time.

Answer 1

@Kenn Devine ,

First of all my apologies for the delayed reply on this. I was not able to get proper information on the same and it took time. Coming back to your question , you mentioned that you have 40 users in your environment and majority of them are in the field hence I will base my answer on the same. I will try to answer your query by touching each and every aspect of your question.

When you say M365 security account database, I think you are comparing with the security accounts manager on windows . It is not exactly same as on-premise Active directory. When you say pull the database over VPN into a non-MS device , i don't think you can do it in normal sense of the word. However you can query the user store using Microsoft Graph API or if the NAS device supports Azure AD integration , you can use the same. This capability needs to be provided from the NAS side so you will need to check with the NAS vendor about this. NAS products generally either create file shares in a windows network or provide capability to create a virtual computer object in your local active directory where you can create as many shares you need to provide to your users over SMB protocol .

When you create a M365 directory you get a directory name like contoso.onmicrosoft.com which is a user-store and auth-system combined just for your company in a geographically distributed online service called azure active directory. It only supports authentication and access over Http based protocols (like SAML,WSFed,oAuth, OpenID connect) unlike the onpremise windows systems which will provide you support for legacy on-prem auth protocols like (Kerberos,NTLM). Azure AD does not have a support for these. Hence you will not be able to query contoso.onmicrosoft.com . In layman's term you can think of onmicrosoft.com as a root directory and contoso being your subdomain for your company but you cannot connect to this directory using LDAP protocol as its not designed in same way as on-premise active directory.

You mentioned that you tried to join a VM to the M365 network after creating the VN gateway and site-to-site VPN to the Azure active directory instance for your company but you would not succeed here because LDAP is not supported in this online directory system. Its not a domain controller where you can add a new VM as a additional domain controller and have active directly replication replicate the same AD database to your VM which you promoted as a Domain controller. We have another product called Azure Active directory Domain Services which you can enable on your azure AD tenant called contoso.onmicrosoft.com . You can then connect to this directory using a public custom domain. It is like a managed Active directory domain that you create with limited capabilities . You would not be able to access the console session on any DCs in this environment but you can connect using secure LDAP and any applications which require Kerberos or NTLM to work can work in cloud if you move the application server on Azure as a new Azure VM connected to same Virtual network which is used as a management network for these managed domain controllers. It is designed in this way to provide a way to run old and legacy applications in the cloud. Please check the diagram below. Its not that great but its helpful in providing you the explanation for the work that we do.

So generally in an on-premise environment we have active directory which is synced to azure Active directory tenant . This syncs the Identities (users,devices etc.) to azure. As I explained above Azure AD is a online directory service where you can store users and use it for authenticating to different applications using web based auth protocols. Generally when you onboard to Azure AD, you add your company's email domains called custom domains to the azure AD tenant/M365 tenant . Now the users that you have in M365 can be provisioned with different services like Exchange email , Teams, Intune etc. In order to provide organisations a capability to run old legacy applications depending upon Kerberos/NTLM protocols without support for modern web based auth protocols like oAUth etc., we created this new product called Azure AD domain services. You require an existing azure AD tenant in order to enable Azure AD domain services. Once you enable Azure ADDS you can add a publicly rotatable domain to the system while setting it up . The domain must be owned by you and verified in the Azure AD tenant. you can choose to run it with a local domain like abc.local but that will not allow you to setup secure LDAP over the internet as the domain is not publicly rotatable. In the back-end two domain controllers are created for your managed domain which are managed by Microsoft and a virtual network also gets created in your subscription. The two DCs reside in a subnet which also houses these two DCs in the backend. You will not be able to directly RDP into them. There is a default NSG which is associated with the subnet and you can setup the rules as default. If you try to open any specific network rules for accessing back-end DCs , the NSG rules will be overwritten to default periodically every few hours so you should not edit them as any change will be overwritten again by the back-end process to prevent any kind of attacks to the managed domain. So you can create a new VM in the azure and connect it to same subnet within the managed domain VNET and use this as a management VM or a jump server by joining it your Azure AD DS domain. You can install the RSAT tool on this server and connect to the PDC to manage it . Azure AD will automatically sync the users to the Azure ADDS instance (or managed domain) . but for the users to be able to logon to the managed domain , their passwords will need to be reset once. Currently you have two different Identities in your setup for every user. A user have their on-premise user ID from on-prem AD and another one is form M365 system. So essentially the users in your environment do not use Single sign-on . Now coming back to your setup , you have 40 cloud-only user accounts and Azure AD does not create Kerberos/NTLM hashes for cloud only users hence all the users would need to change their password after managed domain has been enabled. Because the password change will trigger creation of Azure AD auth hashes along with Kerberos / NTLM hashes for the user . You can force all users to reset their password once managed domain is enabled. The users and password will automatically synced background to the managed domain . I have linked multiple articles here and I would like you to go through them to understand more. also you can not add any domain controller to this managed domain or enhance the schema of the same. There is no backward sync from Azure AD domain services to Azure AD so if you create any user in Azure AD domain services managed domain then they only remain in there and are not replicated back to azure AD. There are certain restrictions for which I would like you to check the documentation.

I believe that after the above explanation , you would be able to understand your options here and see what are the possibilities more clearly . I can suggest you two options here both depending upon a good site-to-site VPN since you have a small environment and majority of your users are working remotely. Also I would suggest to upgrade all your users to latest windows 10 (at least v1803) which will enable you to manage devices in your organisation using intune and have them registered to your Azure AD. you would require to test this before going to production .

1. If your client is looking for removing the 2012 essentials server and they would like to just use that smart NAS device on-premise then you can setup a site to site VPN and open relevant ports so that the Managed domain DCs are automatically in line of sight for the Smart NAS device and it can interface with them over LDAP . However this will stop working anytime the site to site VPN goes down. another way is to setup secure LDAP connection to the Azure AD domain services instance and connect to the managed domain using it . This will require some setup and your smart NAS device must support this secure LDAP connectivity .
2. Since you will still have some users working out of an office and you may use Smart NAS a file store over SMB requiring AD authentication, you can have another way as well. You can create an additional domain controller in addition to the W2012 R2 essential server directly in azure. You will need to have a site to site vnet gateway connectivity between your on-premise office to azure cloud for the same. I think you already had setup earlier before posting this query hence I will not explain that part. Once you have an additional domain controller setup in the cloud , demote the essentials server on-premise. The users will be able to logon still using the new DC in azure, however it again creates dependency on site-to-site VPN. you would require to have a resilient network device which maintains it continuously without any issue. Now in order to setup sync from your new DC to Azure AD , you can install azure AD connect either on same domain controller VM or create a new azure VM . I would recommend a new azure VM for Azure AD connect sync server but you can install it on same server as well. It will just create a single point of failure. The Smart NAS can be connected directly to this Azure VM domain controller. And once this is setup , you can setup sync between the Azure AD and your domain controller environment which will be acting as an extension of your on-premise environment in azure. Thus your users will be able to use single sign-on now as sync with azure AD will be working .

I understand that this answer might be a little long however I am trying to provide you the best possible suggestion with all details suitable for your current environment. If the information is helpful to you , please do accept this as answer so that this is helpful to other community members searching for similar answer. Please go through the linked articles and it will help you make a decision on what architecture should you use. In case I have misunderstood your requirement or you have further queries , please do let me know in comments further and I will continue to help you on the same.

Thank you.