For some time, we have supported joining our containers to Active Directory. Its function that’s always been built-in to our technology from its inception. There are several reasons why a customer might want to go down this route. Firstly, I should say we do usually try to avoid it mainly because it’s an extra piece of configuration to consider before going into production – with that said in many cases, it’s an unavoidable requirement of the containerized application.
AD Authentication became endemic as soon as Microsoft won the wars of the Directory Services fought against Novell NDS. Those wars remain firmly in the past, and you’ll find AD based authentication is pretty much the default method for many of the legacy applications – whether that’s some pass-through authentication where no pop-up boxes appear or some propriety UI that confronts the user – either way these methods usually require a computer account in the domain. Of course, nothing stays still – and the rise and rise on non-Windows devices (iPhone/iPad/Android) and web-based applications are fueling authentications methods which although tied to LDAP infrastructure, but use a system of tokens such as SAML/OATH as the protocol for the username/password. So, by a country mile, the primary reason for joining a container to a domain is to meet these authentication requirements – and the way those requirements are often found out is by testing.
The second reason for joining the domain is accessing other resources which may be backed by AD-based ACLs. In the workgroup model, this is going to create some kind of Windows Security box, where the user will need to type their domain credentials. We can store and pass those credentials, but if there’s an excess of them – then sometimes the quickest route to avoid these pop-up box “annoyances” is to join the container to the domain – and course, as soon as one application requires it the rest of the environment benefits from it as well.
There are other use-cases as well – and that’s to leverage other management constructs and tools that are AD domain-based. Not least AD GPOs – whilst the local security policy remains intact inside the container – many organizations would prefer to have an OU and policy setting pushed down to the container. For those organizations using some end-point management tools like SCCM to manage their conventional Windows 10 PCs, they may also wish to use the same management tools to control the software stack. Our general line on this is – fill your boots. Droplet isn’t about imposing restrictions on how you manage your stuff, nor are we about creating another “single pane of glass” for you to navigate through. But rather empower you to leverage your already very serviceable management infrastructure.
Finally, there’s one other reason to join the container to the domain – and that’s to take advantage of our multi-session capabilities. This is a scenario where the container runs in either a Remote Desktop Session Host (aka Terminal Services) or Windows WVD where Windows 10 multi-session is in use. It also applies to scenarios where more than one user logs into the same physical PC at the same time using the Microsoft “Switch User” feature – this is a common requirement in healthcare settings where staff on shift-share the same Windows PC and toggle between users using the “Switch User”. Of course, in the multi-session environments where one container provides applications for many users – we tend to use our 64-bit container type as it offers great memory scalability – and we need to separate the different users by their userID to prevent one user from getting the Droplet Seamless Apps of another. Whilst you could create users inside the container – that makes no sense logically when there is an AD environment in place.
The joining to the domain process is no different from the process you would use on a physical Windows PC. However, this is a manual process, so we provide customers a series of complementary scripts that automate this process. This includes are “arming” process so as a container is deployed on the first start-up it runs through these scripts which automates changing the computer name, joining the domain itself (creating the computer accounts in a designated OU), and ends by ensuring various AD-based groups allow access to the Droplet Seamless App. At the same time the default logon process is modified by changing an option in the settings.json:
This setting essentially turns off our default login process using our service account and instead challenges the user to supply their domain password.
By default, end-users will see the Windows Security dialog box connecting through to the container listening on the internal, non-routable IP address of 127.0.0.1. This uses the discrete, encrypted private network channel created between the host device and the container itself. Some customers like this approach as they see it as an additional layer of security, especially those organizations that have acquired third-party software that augments these MSGINA dialog boxes with other functionality. As you can see the domain/username is already pre-filled, or that we are waiting for is their password.
If customers would rather pass through the credentials from the main Windows 10/2016/2019 logon. That’s very easy to do with a couple of minor changes in the GPO that focused on the Windows systems run our software is all that’s needed. Again, we supply the documentation to configure those options if desired.
Other Considerations:
Now that the container is joined to the domain there are some other considerations and configurations to think about. By default, the Microsoft Firewall inside the container is turned off. We do not need it – because we have our firewall configuration. However, joining a container to the domain, means there’s a good chance that domain GPO could turn back on the “Domain Profile”. This policy won’t stop our core technologies – but it can stop the Droplet Fileshare service and stop our UsbService both of which are network processes. This triggering of the Windows Firewall can be stopped by enabling this disabling policy (did you see what I did there?)
Computer Configuration > Administrative Templates > Network > Network Connections > Windows Defender Firewall > Domain Profile
The policy-setting “Windows Defender Firewall: Protect all network connections” can be set to disable for a GPO that filters just on the container computer object in Active Directory:
Another consideration is user profiles – as soon as multiple users are login in into the container this will generate a user profile. In most cases, this isn’t an issue because organizations have already a profile management system in place – not least Microsoft own roaming and mandatory profiles. That said it shouldn’t be overlooked – not least that the creation of the profile isn’t very quick, and the last thing you’d want is multiple containers with multiple different local profiles being created.
So that’s joining the container to the domain in a nutshell – mainly done for applications that require AD authentication and with our “multi-session” based containers used in RDSH and Windows WVD environments.