WO2022103882A1 - Virtual room directory service - Google Patents

Abstract

A Desktop-as-a-Service (DaaS) System running on a cloud computing facility is described that provides a directory service, and that can interoperate with an associated controlled access infrastructure system running on a corporate LAN, the DaaS System comprising: an interface to a zero-trust connection between the DaaS System and the controlled access infrastructure system, a virtual room comprising a plurality of virtual desktops, a first directory service domain controller for implementing and managing a group policy that can be applied to the virtual desktops, and a zero-trust access module for implementing the zero-trust connection. The virtual room runs in a virtual machine or container installed on the cloud computing facility, and directory services (including group policies) for that virtual room can be provided by the domain controller without requiring access to any resource in the controlled access infrastructure system.

Description

VIRTUAL ROOM DIRECTORY SERVICE

Cross-Reference to Related Application

[0001] This patent application claims priority to and the benefit thereof of U.S. Provisional Patent Application Serial Number 63/112,503, filed November 11, 2020, the disclosure of which is hereby incorporated by reference in its entirety.

Field

[0002] This specification relates generally to providing directory services to users of Desktop-as-a-Service (DaaS) Systems, and, in some embodiments, to using directory services to provide customized DaaS sessions to users.

Background

[0003] Desktop-as-a-Service (DaaS) Systems

[0004] "Desktop" applications are software applications that have traditionally been delivered by an organization to various users of those applications, by providing them as part of a client computer. A user that receives such a client computer, "accesses" the included desktop applications using one or more icons on the home screen (or "desktop)" of that client computer. Examples of desktop software applications are Microsoft's Word, Excel and Outlook programs, which respectively provide a word processor, a spreadsheet, and an email/calendar application. Examples of client computers capable of running such desktop software applications, are desktop computers and laptop computers. "Access" herein, refers to use of a resource such as an application, by a user that is authenticated, and based on that authentication, authorized to access that resource. Taking as an example the way in which employee computing has been traditionally facilitated by employers, in the traditional desktop application delivery model, the employer provides each employee with a client computer that has installed upon it desktop applications, and gives each employee the required authentication credentials and permissions on that computer for accessing the applications. [0005] By contrast, a Desktop-as-a-Service (DaaS) system ("DaaS System") provides a user ("DaaS User") access to such desktop software applications in the form of a service that is provided over the Internet. Drawing on a more modern version of how employee computing has been facilitated by employers, an example of a DaaS User can be an employee accessing work-related Microsoft Excel spreadsheet files while on vacation in a remote overseas location without an employer-provided client computer. To access that spreadsheet, such a DaaS User need not have in her possession an employer-provided client computer with Microsoft Excel installed thereon and the spreadsheet files stored therein. Rather, the DaaS User can access the spreadsheet using just a web browser (provided it is compatible with the DaaS System) that can be running on any client computer (e.g., the hotel's computer). In this example, the Microsoft Excel files are stored on a server that is remotely located from the employee/hotel, the Microsoft Excel application runs on that server or on another remotely located server, and both the spreadsheet files and application can be remotely accessed by the employee using a client device having just an Internet connection and a web browser (e.g., the hotel's computer). The Microsoft Excel application and spreadsheet file are accessed by the vacationing employee as a DaaS, which has been procured on her behalf by her employer (the employer being an example of a "DaaS Organization", which is an organization that procures a DaaS for one or more of its associated DaaS Users).

[0006] A Software-as-a-Service vendor, hereinafter referenced as a "DaaS Technology Provider," provides the technology that enables the Microsoft Excel spreadsheet to be remotely accessed by the DaaS User across the Internet. Microsoft is an example of a DaaS Technology Provider (i.e., when it provides access to Microsoft Excel as part of its Office 365 Cloud service). Tehama Inc. of Ottawa Canada, which is the assignee of this patent application and provides a DaaS called "Tehama Virtual Desktop," is another example of a DaaS Technology Provider. Turning back to the employee-employer example of the previous paragraph, the DaaS Organization (i.e., the employer) is typically a customer of a DaaS Technology Provider (e.g., Microsoft).

[0007] A suite of one or more computer desktop software applications delivered as a DaaS, is often referred to as a virtual desktop, and server-based applications comprising that suite are often referred to as virtual applications. They are described as "virtual" because though the outputs of the applications are presented at the client computer being operated by the DaaS User (i.e., the hotel computer in the example of the vacationing employee), most of the software implementing those applications executes on the DaaS System running on remotely located server computers, rather than on the client computer being directly operated by the DaaS User. Though the client computer being operated by the DaaS User gives the impression that it is itself running desktop software applications, it is in fact only running graphics-rendering software, such as web browser software for communicating with the DaaS System, to enable a DaaS session for a user.

[0008] As described in the previous example, by receiving access to virtual desktops and applications, a DaaS User can advantageously access applications and data associated with a DaaS Organization from virtually anywhere in the world. Providing such access also has at least one other advantage; it gives a DaaS Organization greater control over the delivery, use, and maintenance of desktop software applications, as compared to the control it could exert had it distributed those applications to its users by providing them a client computer having the applications installed thereon. Again, returning to the example of the vacationing employee, her employer has far more control over her use of the Microsoft Excel application and spreadsheet file when she accesses them using a DaaS, than when she accesses them using a client computer (e.g., a portable laptop computer) that was provided to her by the employer and then brought with her on vacation.

[0009] DaaS Systems Delivered Over the Cloud

[00010] In recent years, DaaS Systems have evolved to deliver virtual applications and virtual desktops using convenient, cost-effective and always-on public cloud computing facilities (individually or collectively hereinafter referred to as the cloud), as opposed to computing facilities that are privately owned by either a DaaS Technology Provider or a DaaS Organization. Examples of such public cloud computing facilities are those offered to the public by Alphabet Inc. (Google Cloud Platform) or Amazon.com Inc. (Amazon Web Services, also known as AWS). More specifically, a DaaS Technology Provider can install and execute its DaaS System on one or more servers in the cloud, and then sell metered access to that DaaS System to one or more DaaS Organizations. Each of these DaaS Organizations, in turn, can upload some of its data to the DaaS System, and then provide credentials to its DaaS Users for enabling them to access the DaaS System and the uploaded data. The DaaS Users can then access the DaaS System's virtual desktops and applications using the convenient, cost-effective and always-on compute facilities of the cloud, rather than the compute facilities of their associated DaaS Organization.

[00011] A DaaS Organization will often need its DaaS Systems that are running on the cloud, to interoperate with systems running on its own corporate local area networks (LANs) (i.e., located on its private premises). This interoperability is typically facilitated by software that is provided by the DaaS Technology Provider, and that runs in both the DaaS System (i.e., on the cloud) and the DaaS Organization's corporate LANs. Such interoperation allows a DaaS Organization to provide DaaS Users with access to applications and data located on one or more of its corporate LANs, in addition to applications and data that have been uploaded to the DaaS System itself.

[00012] Security Vulnerabilities of DaaS Systems

[00013] Although convenient, cost-effective, and always on, cloud-based DaaS Systems can cause heightened security vulnerabilities when they interoperate with applications and data located on one or more corporate LANs of a DaaS Organization. In part, this is because such a cloud-based DaaS System can provide DaaS Users access, via the cloud, to mission-critical and/or data-sensitive resources located on those corporate LANs. An example of such a mission-critical and/or data-sensitive resource is a path to a critical and confidential file (i.e., a location of the file).

[00014] To enable a DaaS Organization to provide a DaaS over a public cloud without exposing its LAN-based resources to cloud-originated security vulnerabilities, some DaaS Systems provide cloud-based DaaS using virtual rooms. A virtual room is DaaS Technology Provider software that runs in one or more virtual machines that run on a cloud and are networked with each other, and that provides a DaaS to one or more users. One or more containers (e.g., a Docker container installed on the cloud having several security features, as known to those skilled in the art, and as described at https://www.docker.com) run inside each virtual room. A virtual room provides a set of virtual desktops and virtual applications for DaaS Users, while being programmable so as to constrain the actions taken by DaaS Users on the virtual desktops and applications. This programmability, along with the sorts of security features made available by containers, make a virtual room a vital component of a DaaS System. The use by a DaaS Organization of virtual rooms in its DaaS System, better secures the LAN-based mission-critical and/or data-sensitive resources of that DaaS Organization.

[00015] Directory Services and Group Policies

[00016] In a traditional local area network (LAN), a directory service is a customizable information store (i.e., a structured file) that a client computer uses, as a single point of reference, for locating compute resources that are controlled by server computers on that same LAN. More specifically, a client computer can use a directory service to locate a computer resource required by one of its applications, when that resource is controlled by one or more servers. Examples of such a resource are a printer controlled by a server, a computer file repository stored on a server, and an Internet gateway connection reachable through a server. Directory services may be used to enable centralized management by LAN administrators over key user and security settings, such as which files, applications, and/or printers can be accessed over the LAN by a given user logged into a given client computer. Examples of directory services are Microsoft's Active Directory (AD) for Windows-based client computers, and the Apple Open Directory for Mac-based client computers. Directory services are installed on servers called domain controllers, which are typically located on the LAN.

[00017] Directory services have been especially popular because they allow LAN administrators to centrally manage users and/or their client computers using group policies. A group policy is a a set of directory service settings common to some subset of users and/or client computers, such as some or all employees of a particular organization (e.g., employees belonging to the IT Department, or employees who are authorized to work remotely from the office). A LAN administrator who makes a single change to a single group policy setting with a touch of a button, can rely on the directory service to apply that single change to all users and client computers associated with that group policy. For example, a group policy prohibiting access to a given file can be applied to all employees of a DaaS Organization who are not in the IT Department, but at a touch of a button, that group policy can be altered to prohibit all employees of a DaaS Organization who are not managers in the IT Department from accessing that file. Group policies may be used to control a range of directory service features, for example desktop branding, security related settings such as Internet privacy settings, access control lists, notifications, reboot settings, and/or automatic installation of applications. Typically, users cannot override group policies using their client computers.

[00018] DaaS Organizations want to enjoy the benefits of group policies, whether managing locally-located users of client computers connected to the organization's LANs (i.e., using a traditional directory service as described in the previous two paragraphs), or managing remotely located DaaS Users of virtual desktops provided over the Internet. A typical DaaS Organization is especially keen to enjoy such benefits because any of its LAN-based users can in effect, become cloud-based DaaS User within minutes, by simply changing location from the premises of the DaaS Organization (such as the office during a workday) to a remote location (such as a home office or distant hotel later that day). In such a situation, it would be desirable for a change made to a group policy associated with a subset of users (for example, a new restriction prohibiting employees not in the IT Department from accessing a given file) to be applied to all such users, whether they are using a traditional desktop application running on a LAN-connected client computer or a virtual desktop application running on a remotely located DaaS System.

[00019] Conventional Directory Services Offered on DaaS Systems

[00020] Conventional DaaS System directory services either cause heightened security vulnerabilities for DaaS Organizations, or sacrifice support for feature-rich group policies in addressing the security vulnerabilities. For example, AWS can install a Microsoft Active Directory service (i.e., a directory service marketed by Microsoft) in each virtual room it instantiates for DaaS Organizations. When this directory service is used by a DaaS Organization (i.e., an AWS customer), the contents of each directory installed in each AWS-based virtual room are replicated in the corporate LAN of the associated DaaS Organization. That is, under the AWS architecture, the contents of the directory installed on a domain controller in the DaaS Organization's virtual room (i.e., on the AWS cloud), also need to be on the directory installed on a domain controller in the DaaS Organization's LAN (i.e., in the DaaS Organization's private premises). This replication is effected so that directory services enjoyed by users logged into the DaaS System, can be enjoyed when those same users log into the corporate LAN.

[00021] FIG. 1 illustrates such a conventional DaaS System on a cloud 210 connected to a corporate LAN 202 via a secure pipe 220 (i.e., a secure transport control protocol (TCP) connection). The corporate LAN 202 may include a first LAN-based directory domain controller 204, and the DaaS System 210 may include a second active DaaS-based directory domain controller 212, both of which remain synchronized so that they describe and have access to an identical set of resources. The LAN-based directory domain controller 204 may communicate with a file share repository 206 on the corporate LAN 202. The corporate LAN 202 may also include databases / applications 208, many of which may be mission-critical and/or data- sensitive. The DaaS-based directory domain controller 212 may communicate with one or more virtual desktops 216 via an active directory connector 214. The secure pipe 220 is used to communicate the updates required to keep the LAN-based directory domain controller 204 synchronized with the DaaS-based directory domain controller 212.

[00022] The secure pipe 220 includes one or more two-way trust connections 222, and may also include replications 224 thereof. Each two-way trust connection 222, 224 implements a two-way trust relationship between the directory domain controller 212 on the DaaS System 201, and the directory domain controller 204 on the corporate LAN 202. Two-way trust relationships are known to those skilled in the art and are described, for example, at https://www.pearsonitcertification.com/articles/article.aspx?p-170286&seq Num-2. By way of background, three types of trust relationships are presently described:

In a one-way trust relationship, an administrator can configure one security domain (such as the DaaS System 210) to trust a second security domain (such as the corporate LAN 202), so that users having accounts in the second domain could access resources in the first domain. The domain in which the resources to be accessed are located is referred to as the trusting or resource domain, and the domain in which the accessing accounts are kept is referred to as the trusted or accounts domain. In a one-way trust relationship, the trusting domain makes its resources available to the trusted domain; that is, users in the trusted domain are able to access resources in the trusting domain. The trusted domain however, does not make its resources available to the trusting domain; users in the trusting domain are unable to access resources in the trusted domain.

• In a zero-trust relationship between security domains, neither domain trusts the other domain, making it impossible for either domain to access the resources of the other domain.

• In a two-way trust relationship between domains, there simply is the concurrent existence of two one-way trust relationships in opposite directions between the domains.

[00023] In operation, the conventional architecture of FIG. 1 maintains replication of the directories 204, 212, using a two-way trust relationship between the directory domain controller 204 running in the DaasS Organization's corporate LAN 202 and the directory domain controller 212 running in the cloud-based virtual room 102 of the DaaS System 210. To maintain a state of replication between the two domain controllers 204,212, a change in the directory of either controller 204, 212 is communicated to the other controller 212, 204, using the two-way trust connections of the secure pipe 220.

[00024] The two-way trust relationship of the conventional directory service arrangement of FIG. 1 creates a risk however, which is that a DaaS User on the DaaS System 210 might improperly access a mission-critical and/or data-sensitive resource in the corporate LAN 202. Such a risk is especially likely in the architecture of FIG. 1 because a DaaS User logged onto the DaaS System 210, can in effect look inside the directory service domain controller 204 of the corporate LAN 202, by simply accessing the replicated directory domain controller 212 of the DaaS System 210. This would be especially dangerous in the context of a "Golden Ticket Attack" on the corporate LAN 202, in which an ill-intentioned DaaS User might use its effective access to the directory service domain controller 204 of the corporate LAN 202, to obtain information required for the attack (e.g., the names of users that can access highly confidential files, etc.).

[00025] The Microsoft Active Directory Service of FIG. 1 addresses this risk by in effect admitting that the vulnerability cannot be removed, and focusing instead on minimizing the consequences if such a vulnerability ever materializes. This is done by significantly de-featuring both directory service domain controllers 204, 212, so as not to place any sensitive information about any mission-critical and/or data-sensitive resources associated within either the corporate LAN 202, or the replicative DaaS System based directory domain controller 212. A simple example of such de-featuring would be to not specify which user accounts have access to highly confidential files in either directory service domain controllers 202,212. De-featuring thwarts an unscrupulous DaaS User with access to the replicated directory service domain controller 212, by ensuring that such a user would have no knowledge of such mission-critical and/or data-sensitive resources hosted on the DaaS Organization's corporate LAN 202, even after gaining effective access to the directory service domain controller 204 by virtue of the replication. De-featuring however also results in a reduction of the feature set supported by the directory service, for both users of the DaaS System 210 and the LAN 204, until there is no feature supported by either directory service domain controller that draws upon mission-critical and/or data-sensitive resources located on the corporate LAN 202 such as path names of critical and confidential files. It is for this reason that some conventional directory services are not feature-rich.

[00026] More specifically, as a result of de-featuring, the directory service of the system described in FIG. 1 typically includes only connectivity information for associating each DaaS User with a given virtual desktop 216. More advanced directory service features that require placement of sensitive information on the directory domain controller 212 running in the cloud- based virtual room 102 of the DaaS System 210, are not supported. For example, the directory service domain controllers 204, 212 of FIG. 1, do not include information required to provide feature-rich group policies that follow a DaaS User as he switches between using a virtual desktop on a DaaS System 210 and a traditional desktop of a client computer (i.e., which would be located in the corporate LAN 202). An example of such a feature-rich group policy, which as previously mentioned is unavailable in conventional systems because of security concerns, provides a group of users in the finance department with access to highly confidential audit files that are not made available to any other user, and further provides access to those highly confidential audit files to those same users even as they switch between using a virtual desktop on a DaaS System 210 (at which time they are DaaS Users) and a traditional desktop on a LAN- connected client computer 202. De-featuring such group policies makes it challenging to exercise centralized management and dynamic updates of key user experience and security settings on their DaaS Systems. A need therefore exists to provide DaaS Organizations with such centralized management and dynamic updates, and to preferably customize them on a per-user basis, and to do all of this without providing DaaS Users access to mission-critical and/or data- sensitive resources hosted on the DaaS Organization's corporate LAN 202.

[00027] Summary of the Invention

[00028] Embodiments of the invention provide DaaS Organizations a directory service for a DaaS System, that supports centralized management and dynamic updates of key user experience and security settings on their DaaS Systems, without compromising mission-critical and/or data-sensitive resources hosted on the DaaS Organization's corporate LAN. At least one embodiment of this disclosure can do so using key user experience and security settings that are customized on a per-user basis.

[00029] A directory service providing centralized management and dynamic updates of key user experience and security settings on DaaS Systems is provided in a first embodiment based on the following discovery made by the inventors: a directory service running in a virtual room of a DaaS System can include information that is rich enough to support a group policy, without exposing any mission-critical and/or data-sensitive resources of an associated corporate LAN, provided the scope of that group policy is limited to all virtual desktops in each virtual room. Such a "virtual-desktop-focused" group policy, unlike a group policy whose scope is an individual DaaS User or an individual virtual desktop, does not need to draw upon any mission- critical and/or data-sensitive resources of an associated corporate LAN. The directory services architecture of the first embodiment leverages this discovery by (a) supporting only group policies that are applied to all the virtual desktops in each virtual room, and (b) including a zerotrust connection between the DaaS System and the corporate LAN that prevents either from accessing the resources (including mission-critical and/or data-sensitive resources on the corporate LAN) of the other. This embodiment thus allows a DaaS Organization to set up and modify a group policy for all the virtual desktops of its virtual room (i.e., which group policy does not require access to the resources of a the DaaS Organization's corporate LAN) using a zerotrust connection that protects mission-critical and/or data-sensitive resources on its corporate LAN.

[00030] The "virtual-desktop-focused" group policies of the first embodiment provide the DaaS Organization centralized management of virtual desktops on a per-room basis, allowing for centralized control of the appearance, composition, and maintenance of all of the virtual desktops running in a virtual room with the invocation of a single command. Virtual-desktop- focused group policies allow an administrator to configure hundreds of potential settings for potentially hundred or even thousands of virtual desktops in a virtual room, by altering a single feature of that group policy at the touch of a button. Because such virtual-desktop-focused group policies cannot be "user-focused" however, they cannot vary from DaaS User to DaaS User, which means they cannot be applied to a user that switches between virtual desktops, or a user that switches between a virtual desktop on a DaaS System and a desktop on a client computer located inside the DaaS Organization's corporate LAN.

[00031] A directory service for a DaaS System that supports such "user-focused" group policies, without compromising mission-critical and/or data-sensitive resources hosted on the DaaS Organization's corporate LAN, is accomplished in a second embodiment of this disclosure. The second embodiment is based on the following additional discovery made by the inventors: by designating the corporate LAN's directory service domain controller as the primary directory service domain controller for the entire DaaS Organization with primacy over all directory service domain controllers in the DaaS System (i.e., primacy over all directory service domain controllers in the cloud), it becomes possible to support advanced directory services (including group policies) for DaaS Users originally authenticated by the primacy-status LAN-based directory service domain controller (i.e., such a user hereinafter, a "trusted" user) without exposing mission-critical and/or data-sensitive resources of the corporate LAN from the DaaS System. The directory service architecture of the second embodiment leverages this discovery by (a) designating the corporate LAN's directory service domain controller as the primary directory service domain controller for the entire DaaS Organization, with primacy in particular over all directory service domain controllers in the DaaS System / cloud, and (b) using a oneway-trust connection to connect the DaaS System and the corporate LAN, in which the DaaS System is in the trusting domain, and the corporate LAN is in the trusted domain.

[00032] The primacy of the DaaS Organization's LAN-based directory service domain controller over its DaaS-System-based directory service domain controllers, means that the DaaS Organization's LAN-based directory service domain controller can control the DaaS- System-based directory service domain controllers, in order to provide directory services to a user that has been properly authenticated in that LAN-based directory service domain controller's domain (a trusted user), even when that user is roaming to a DaaS System and thus becomes a DaaS User. When such a trusted user roams to a DaaS System and becomes a trusted DaaS User, she interacts with a DaaS-based directory domain controller (which is no longer a replication of the LAN-based directory domain controller, as was the case with the conventional DaaS System illustrated in FIG. 1). That DaaS-based directory domain controller in turn provides directory services to the trusted DaaS User by interacting with the primacy-status LAN-based directory domain controller, which itself has the required directory services information to provide the trusted DaaS User many of the same directory services she enjoys when logged into the corporate LAN. This means the authenticated LAN-based user (the trusted user), when logged into the DaaS System, can access the same directory services as any other DaaS User (i.e., untrusted DaaS Users), as well as all the directory services she enjoys when directly logged into the LAN. And the trusted DaaS User can enjoy these feature-rich directory services without requiring the sensitive information of the LAN-based directory domain controller to be replicated on the DaaS System, and thus without that information being made accessible to untrusted DaaS Users who have access to the DaaS-based directory service domain controller.

[00033] The operation of the one-way trust connection means that the converse is not true, in that untrusted DaaS Users that lack access credentials in the domain of the LAN-based directory domain controller, cannot directly access the LAN-based directory domain controller.

[00034] The resulting directory service architecture supports both virtual-desktop-focused group policies for all the virtual desktops in a virtual room (i.e., as supported by the first embodiment), and user-focused group policies for individual trusted users that have already been authenticated by the primary directory service domain controller in the DaaS Organization's corporate LAN.

[00035] Under this second embodiment, a DaaS User that is already authenticated in the corporate LAN (i.e., a trusted user from the trusted domain) can benefit from advanced directory services (including group polices) that draw on mission-critical and/or data-sensitive resources hosted on the DaaS Organization's corporate LAN, even when operating a virtual desktop in a cloud-based virtual room (i.e., even while logged into the DaaS System as a DaaS User). A DaaS User in that same virtual room who has not been authenticated in the corporate LAN however (i.e., a user from the trusting domain not the trusted domain), cannot access mission-critical and/or data-sensitive resources hosted on the DaaS Organization's corporate LAN and therefore cannot benefit from those same advanced directory services (including feature-rich group polices). By supporting user-focused group policies that can vary from trusted DaaS User to trusted DaaS User even as that trusted user switches virtual desktops, or switches from a virtual desktop on the DaaS System to a client computer on the DaaS Organization's LAN, directory services that span the cloud (i.e., that extend into the DaaS System) and the corporate LAN become possible for trusted users. This in turn facilitates heretofore unachievable customized directory services to be offered to trusted users, as described below. Brief Description of the Drawings

[00036] The drawings accompanying and forming part of this specification are included to depict certain aspects of embodiments of the present disclosure. A clearer impression of embodiments of the present disclosure, and of the components and operation of systems provided with embodiments of the present disclosure, will become more readily apparent by referring to the exemplary, and therefore non- limiting, embodiments illustrated in the drawings, wherein identical reference numerals designate the same components. Note that the features illustrated in the drawings are not necessarily drawn to scale.

[00037] FIG. 1 illustrates a conventional directory service for a DaaS System that includes replicated directory service domain controllers on both a cloud-based DaaS System and a corporate LAN.

[00038] FIG. 2 illustrates a directory service for a DaaS System according to a first embodiment of the present disclosure that supports "virtual-desktop-focused" group policies and uses a zero-trust connection between the DaaS System and a corporate LAN.

[00039] FIG. 3 illustrates a directory service for a DaaS System according to a second embodiment of the present disclosure that that supports "user-focused" group policies, and uses a one-way trust connection between the DaaS System and a corporate LAN.

[00040] FIG. 4 illustrates the messages exchanged between the directory service domain controller in the cloud-based DaaS System, and the directory service domain controller on the corporate LAN, to implement the one-way trust connection illustrated in FIG. 3.

Detailed Description

[00041] This disclosure and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the disclosure in detail. Skilled artisans should understand, however, that the detailed description and the specific examples, while disclosing preferred embodiments, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions or rearrangements within the scope of the underlying inventive concept(s) will become apparent to those skilled in the art after reading this disclosure.

[00042] Reference throughout this specification to "one embodiment", "an embodiment", or "a specific embodiment" or similar terminology means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment and may not necessarily be present in all embodiments. Thus, respective appearances of the phrases "in one embodiment", "in an embodiment", or "in a specific embodiment" or similar terminology in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics of any particular embodiment may be combined in any suitable manner with one or more other embodiments. It is to be understood that other variations and modifications of the embodiments described and illustrated herein are possible in light of the teachings herein and are to be considered as part of the spirit and scope of the present disclosure.

[00043] In the description herein, numerous specific details are provided, such as examples of components and/or methods, to provide a thorough understanding of embodiments of the present disclosure. One skilled in the relevant art will recognize, however, that an embodiment may be able to be practiced without one or more of the specific details, or with other apparatus, systems, assemblies, methods, components, materials, parts, and/or the like. In other instances, well-known structures, components, systems, materials, or operations are not specifically shown or described in detail to avoid obscuring aspects of embodiments of the present disclosure. While the present disclosure may be illustrated by using a particular embodiment, this is not and does not limit the present disclosure to any particular embodiment and a person of ordinary skill in the art will recognize that additional embodiments are readily understandable and are a part of the present disclosure.

[00044] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, product, article, or apparatus that comprises a list of elements is not necessarily limited only those elements but may include other elements not expressly listed or inherent to such process, product, article, or apparatus.

[00045] Furthermore, the term "or" as used herein is generally intended to mean "and/or" unless otherwise indicated. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present). As used herein, a term preceded by "a" or "an" (and "the" when antecedent basis is "a" or "an") includes both singular and plural of such term, unless clearly indicated otherwise (i.e., that the reference "a" or "an" clearly indicates only the singular or only the plural). Also, as used in the description herein, the meaning of "in" includes "in" and "on" unless the context clearly dictates otherwise.

[00046] FIG. 2 illustrates a cloud-based DaaS System 210 and a corporate LAN 202 that provide a secure and feature-rich virtual room directory service according to an embodiment of the invention. The DaaS System 210 comprises one or more virtual room(s) 102 instantiated on a DaaS System in the cloud 210. One or more user devices 106 connected to the virtual room 102 through the Internet 119, and controlled-access infrastructure 104 that is part of the corporate LAN 202, are also illustrated. A zero-trust connection 302 is implemented between the DaaS System 210 and the corporate LAN 202. DaaS System 210 also comprises a directory service domain controller 304. The directory service domain controller 304 can be a standard virtualized directory domain controller as provided by Microsoft, a Lightweight Directory Access Protocol (LDAP) domain controller known to those skilled in the art, or virtually any other type of directory service domain controller. An additional directory service domain controller (not shown) can also be provided as part of the DaaS System 210, and used as a backup in case the directory service domain controller 304 fails to operate correctly.

[00047] The virtual room(s) 102, which is typically provided by a DaaS Technology Provider, may include one or more virtual desktop(s) 108, which may be, for example, Windows or Linux virtual desktops, and which can be supported by a richer set of directory services than the directory services made available to the virtual desktops 216 of the conventional DaaS System 210. It may also include individual virtual applications in addition to or instead of the virtual desktops. A secure perimeter is created around each virtual room 102, by for example implementing it as a software container. The virtual room(s) 102 may further include a router/firewall 110, and one or more room module(s) 114, that may include but are not limited to modules for implementing dynamic firewall rules 116a, policy controls 116b, audits 116c, a secrets vault 116d, a file vault 116e, and zero-trust access control 116f, the latter of which is discussed in more detail below. The user device(s) 106 are client computers remotely located from the DaaS System, and may be desktop computers, laptop computers, tablet computers, smartphones, or other computers made available to users. Controlled-access infrastructure 104 comprises the resources in the DaaS Organization's corporate LAN 202 that need to be secured from unauthorized access from the cloud 210, and include a gateway 112 which is software typically provided to the DaaS Organization by the DaaS Technology Provider, that is supposed to execute inside corporate LAN 202 (i.e., the DaaS Technology Provider supplies the gateway 112 to the DaaS Organization, in addition to providing the DaaS Organization and DaaS Users access to the DaaS System 210). Controlled-access infrastructure 104, also includes mission- critical and/or data-sensitive DaaS Organization resources such as databases/applications 118a. Controlled-access infrastructure 104 also includes hybrid infrastructure 118b for coordinating interactions between the corporate LAN 202 and cloud-based DaaS System 210, and/or Internet gateway control modules 118c.

[00048] A DaaS Organization typically purchases access to a virtual room 102 from a DaaS Technology Provider. A DaaS Organization does not share its virtual room 102 with other DaaS Organizations. DaaS Users associated with the DaaS Organization can operate user devices 106 to access secure virtual desktops 108 that are inside the DaaS Organization's virtual room 102. The virtual room 102 may include controls and capabilities required to, for example, quickly onboard, manage, scale, secure, and/or audit a DaaS User such as an employee or third-party vendor. Virtual rooms 102 may facilitate remote work through several tools and services, including virtual Windows or Linux desktops 108, the secrets vault, 116d, the file vault 116e, and/or precision auditing tools 116c, all without requiring the DaaS Organization to make its LAN 202 based mission-critical and/or data-sensitive resources accessible from the cloud. That is, the virtual room operates as a virtual cloud-based extension of the DaaS Organization's business infrastructure, without necessarily exposing resources on corporate LAN 202 to unscrupulous users of DaaS System 210.

[00049] The virtual room 102 operates as such a virtual cloud-based extension, by providing a properly credentialed DaaS User with access to resources of a DaaS Organization, through a hosted cloud workspace (i.e., through the virtual room 102). Absent security precautions taken by the DaaS Organization and/or DaaS Technology Provider, these resources may be located on the DaaS System 210 or the corporate LAN 202. A virtual room provides secure access to these resources by implementing a proprietary security protocol with the gateway 112 that provides: (i) controlled access to a virtual desktop 108, and along with it, to the room modules 114 of the virtual room 102 and (ii) cloud workspace proxying access to resources (e.g., databases and applications 118a) sitting inside a DaaS Organization's corporate LAN 202.

[00050] In the embodiment of FIG. 2 however, security measures are taken to prevent a DaaS User logged into a virtual room 102 from accessing resources located in a DaaS Organization's LAN 202, for example databases or applications 118a. These measures are the operation of the secure gateway 112, and implementation of the aforementioned security protocol between the virtual room 102 and secure gateway 112, which provides a zero-trust connection 302 between the DaaS System 210 and the corporate LAN 202. As a result of the zero-trust connection 302, software running inside the virtual room 102, including virtual desktops 108 and virtual applications executing thereon, cannot access the resources 118a, 118b, 118c located in a DaaS Organization's corporate LAN 202, and vice versa. By replacing the two-way trust connection of conventional virtual room directory services as described by FIG. 1, with a highly regulated and secure zero-trust connection 302, mission-critical and/or data- sensitive resources on the associated DaaS Organization's LAN 202 are protected from access by the DaaS System 210, without having to defeature any directory services running on the DaaS System 210 as practiced by the conventional system of FIG. 1. [00051] That is, such a zero-trust secure connection 302 does not preclude support for a feature rich directory-based services, and for group policies in particular, on a DaaS System 210, provided the group policies are scoped to all the virtual desktops of a virtual room, rather than to individual DaaS Users or virtual desktops. More specifically, this first embodiment is able to provide DaaS Organizations centralized management and dynamic updates of key DaaS User experience and security settings for all virtual desktops 108 of a virtual room 102. This is accomplished by adding a directory service domain controller 304 to each virtual room, but scoping the services supported by that domain controller 304 to its specific virtual room 102, meaning every virtual desktop 108 in a given virtual room 102 receives the same directory service without any differentiation of the directory services being offered to individual DaaS Users, and without any differentiation of the directory services being supported by one individual desktop 108 as compared to another individual desktop 108. As previously mentioned, group policies, when scoped to virtual rooms are referenced herein as "virtual- desktop-focused" group policies.

[00052] The resulting directory service supports "virtual-desktop-focused" group policies, notwithstanding the presence of the zero-trust connection 302, because such group policies can be setup and operated without providing the DaaS System access to any resources on the corporate LAN 202. This means "virtual-desktop-focused" group policies group policies can be implemented without contravening the operation of the zero-trust connection 302, which protects mission-critical and/or data-sensitive resources on the associated DaaS Organization's LAN 202. More specifically, the DaaS System 210 may communicate with the DaaS Organization's LAN 202 of a DaaS Organization via the gateway 214 to implement "virtual- desktop-focused" group policies on the DaaS System 210, but because implementation of those particular type of group policies does not require access to any resources on the corporate LAN 202, that communication can occur over a zero-trust connection 302 administered by the zerotrust access control module 116f, and does not provide any access to resources on the corporate LAN 202.

[00053] The resulting "virtual-desktop-focused" group policies allow DaaS Organization administrators to configure hundreds of potential settings for all virtual desktops 108 associated with the virtual room 102, which settings range from those governing security and compliance features, to those defining the desktop user experience, and those defining the appearance and composition of virtual desktops 108, etc. Importantly, any feature of all the virtual desktops 108 in a virtual room 102 can be altered with the invocation of a single command. That single command cannot be overridden by a DaaS User's local policies as installed anywhere in that virtual room 102. This novel virtual room directory service therefore enables the DaaS Organization to centrally manage all its DaaS virtual desktops 108, by configuring group policy settings for a virtual room 102 once, and then having that setting be automatically inherited and enforced on every virtual desktop 108 running in that virtual room 102. This novel virtual room directory service also enables the DaaS Organization to dynamically update any setting of every virtual desktop 108 in a virtual room, by modifying the group policy for that virtual room 102. When such an update occurs, it is propagated to every virtual desktop 108 in the virtual room 102, without having to manually change the setting on each virtual desktop 108 or re-image any of the virtual desktops 108. This makes it faster and easier to create a consistent and secure setup across a large number of cloud-based virtual desktops 108, while still securing the DaaS Organization's mission-critical and/or data-sensitive resources on its corporate LAN 202.

[00054] The virtual-desktop-focused group policies provided in the system of FIG. 1 do not support centralized management of individual DaaS Users, and so cannot offer policies that vary from DaaS User to DaaS User even as that user either switches virtual desktop, or switches between a virtual desktop and a client computer located on the DaaS Organization's corporate LAN 202. Such limitations of the virtual-desktop-focused group policies, amount to a necessary tradeoff required to secure the DaaS Organization's mission-critical and/or data-sensitive resources on its corporate LAN 202, while still allowing the DaaS Organization to support feature-rich group policies for DaaS virtual desktops 108. That is, because the zero-trust connection 302 operates to prevent directory service domain controller 304 from accessing resources from the corporate LAN 202, the domain controller 304 is starved of the sort of information it requires from corporate LAN 202 to itself implement directory services scoped to individual DaaS Users. [00055] With reference to FIG. 3, in a second embodiment of the present disclosure, directory services on the DaaS System 210, are implemented in part by a directory service domain controller 416 on the corporate LAN 202, in a manner that enables support of directory services scoped to individual DaaS Users without exposing the mission-critical and/or data- sensitive resources of the corporate LAN 202 to the DaaS System 210. In the directory services architecture of FIG. 3, a virtual room 102 includes a virtual room directory service domain controller 304, and associated virtual desktops 108, and can include the router/firewall 110, and the room modules 114 that can implement any of dynamic firewall rules 116a, policy controls 116b for implementing and managing group policies, audits 116c, secrets vault 116d, and file vault 116e, as in the embodiment described by FIG. 2. An additional directory service domain controller (not shown) can also be provided as part of the DaaS System 210, and used as a backup in case the directory service domain controller 304 fails to operate correctly.

[00056] In this second embodiment however, unlike in the first embodiment, the controlled access infrastructure 104 on the corporate network 102, additionally includes a directory service domain controller 416 that has primacy over the virtual room's 102 directory service domain controller 304. This primacy means that the directory service domain controller 416 and the directory service domain controller 304 can coexist in a single security domain, but within that security domain, only the directory service domain controller 416 takes on a primary role and thus controls the security function and holds master copies of user accounts and permissions. The directory service domain controller 304 takes on a secondary role, does not control the security function for the domain, does not hold master copies of user accounts and permissions, and has to rely on the primary directory service domain controller 416 to provide services to DaaS Users that need to draw on the security function or user account and permission information to provide directory services to DaaS Users. This means a DaaS User who is authenticated under the LAN-based directory service domain controller 416, can use the LANbased directory service domain controller while logged into the DaaS System, instead of using a replication of the LAN-based directory domain controller that has been placed on the DaaS System (as is done with conventional DaaS Systems). The DaaS-based directory domain controller provides feature-rich directory services to DaaS Users that draw upon mission-critical and/or data-sensitive resources of corporate LAN 202 (e.g., a path for a critical and confidential file), by interacting with the primacy-status LAN-based directory domain controller that itself has the required resources (e.g., the path for the file).

[00057] The directory service domain controller 416 can be of standard design, and can be an unmodified Microsoft Active Directory domain controller. As mentioned above, directory service domain controller 416 is programmed to have primacy over the virtual room's 102 directory service domain controller 304, which was not the case in the first embodiment illustrated in FIG. 2. Also unlike in the first embodiment, the virtual room 108 / DaaS System 210 is connected to the controlled access infrastructure 104 / corporate LAN 202 using a oneway trust connection 418, as opposed to the zero-trust connection 302 of the FIG. 2 embodiment. In the one-way trust connection 418, the virtual room 102 (in the DaaS System 210) is in the trusting domain, and the controlled access infrastructure 104 (in the corporate LAN 202) is in the trusted domain. This one-way trust connection 418 means that (i) the DaaS- based directory service domain controller 304 can provide feature-rich directory services (i.e., services that require access to LAN 202 resources) to trusted DaaS Users by interacting with the primacy-status LAN-based directory domain controller 416, which itself has the required directory services information to provide such services, and (ii) that the converse is not true, in that untrusted DaaS Users that lack access credentials to the LAN-based directory domain controller, cannot interact with the LAN-based directory domain controller 416 in any way, and thus cannot access the directory services information of the LAN 202. To facilitate the change in connection from the zero-trust connection 222 of FIG. 2, to the one-way trust connection 418 of FIG. 3, the one-way-trust access control module 416f of FIG. 3 replaces the zero-trust access control module 116f of FIG. 2.

[00058] In the FIG. 3 embodiment, the conventional directory service domain controller 416 running on the DaaS Organization's corporate LAN 202 establishes a one-way trust connection 418 with the directory service domain controller 304 running on the DaaS System 210, using technologies known to those skilled in the art, for example a Samba/Kerberos subsystem running the OpenLDAP protocol as illustrated in FIG. 4. In the Samba / Kerberos subsystem of FIG. 4 for example, the directory service domain controller 416 running on the DaaS Organization's corporate LAN 202, may include domain services module 506, which in turn may include a common internet file system (CIFS) server 510 that uses Kerberos (not shown) as a security protocol, a Microsoft active directory 512 supporting Kerberos and LDAP, and a UNIX module 514. A directory service domain controller 304 running on the DaaS System 210 may include client services module 508, which in turn may include a server message block daemon (Smbd) 516 for providing file and print services for Windows clients, NetBios message block daemon (Nmbd) 518 for replying to service requests from the Cifs 510 and the Smbd 16, a Winbind server 520 for resolving user and group information, and an Nssjdap server 522 as a source for name service information. The CIFS server 510 and the active directory 512 exchanges authentication message 524 with the Smbd 516. The active directory 512 and UNIX services module 514 exchange user ID (UID) / group ID (GID) resolution messaging 526 with the Winbind 520 and the Nss dap 522. All of these modules work together using processes known to those skilled in the art.

[00059] In this second embodiment, as in the first embodiment, exposure to DaaS Users of the mission-critical and/or data-sensitive resources of corporate LAN 202 is still avoided, though this is accomplished in this second embodiment through use of the one-way trust connection 418 instead of the zero-trust connection 302 of the FIG. 2 embodiment. In this second embodiment however, unlike in the first embodiment, feature-rich group policies that draw upon mission-critical and/or data-sensitive resources on the DaaS Organization's corporate LAN 202 can be provided to a certain type of DaaS User, specifically a type of user that has already been trusted to directly access the directory service domain controller 416 of the corporate LAN 202. More specifically, this second embodiment provides two different types of directory service in the virtual room 102 of the DaaS System 210, to two different classes of users:

• Untrusted (External) DaaS Users, who are never authenticated by the corporate

LAN's 202 directory service domain controller 416. Their directory services are provided only by directory service domain controller 304. Such untrusted users would typically only be in an arm's-length contractual relationship with the organization (e.g., contract workers at call centers that are helping customers of an organization, and students being taught by an educational organization such as a university), and have little or no control over their own directory service/ group policy. These users cannot access the mission-critical and/or data- sensitive resources located on the DaaS Organization's corporate LAN 202, and are only provided "virtual-desktop-focused" group policies that are equivalent to the desktop-focused group policies created under the first embodiment of the present disclosure as described above with reference to FIG. 2; and,

• Trusted (Internal) DaaS Users, who are authenticated by the corporate LAN's 202 directory service domain controller 416. Even when such users roam from the corporate LAN 202 to the DaaS System 210 to become DaaS Users, their directory services are provided by the directory service domain controller 416 accessing and controlling the directory service domain controller 304. Such users would typically be in a more legally intimate relationship with the organization (e.g., employees or officers of an organization, or other individuals having a fiduciary relationship with the organization). Such trusted users may have more control over their own directory service/group policy, and can access the mission-critical and/or data- sensitive resources of the DaaS Organization's such as databases/applications 118a whether logged into the virtual room (trusting domain) or the corporate LAN 202 (trusted domain). They can use a virtual desktop 108 in the virtual room 102, when for example working from home or travelling. When using the virtual desktop 108, such trusted DaaS Users are provided directory service and group policy settings that are inherited from the ones they use when they are logged into a client computer on the DaaS Organization's corporate LAN 102. These trusted users are provided directory services and user-focused group policies that are not available to any untrusted user, including any user under the first embodiment of the present disclosure as described above with reference to FIG. 2.

[00060] For trusted users therefore, group policies can be user-focused. Such "user- focused" group policies support centralized management of individualized DaaS Users (as opposed to just centralized management of all virtual desktops as a collective), and so can offer centrally managed policies that vary from trusted DaaS User to trusted DaaS User and from virtual desktop 108 to virtual desktop 108. For example, the directory service domain controller 416 of FIG. 3, may include information required to provide feature-rich group policies that follow a trusted user as he switches between using a traditional desktop on a LAN-connected client computer 202 and a virtual desktop on the DaaS System 210. When such a trusted user roams to the DaaS System and becomes a trusted DaaS User, he interacts with directory service domain controller 304, which in turn interacts with the primacy-status LAN-based directory service domain controller 416, to provide that trusted DaaS User feature-rich group policies for example. An example of such a feature-rich group policy provides a group of LAN-based 202 trusted users in the finance department with access to highly confidential audit files that are not made available to any other user, and further provides access to those highly confidential audit files to such trusted users when they log into a DaaS System and become trusted DaaS Users. Under this example, the DaaS Organization would have the capability of altering the features of the finance department group policy, by for example altering the list of files made accessible to all users of that group whether they are on the LAN 202 or the DaaS System 210, and apply those altered features to all trusted users, whether or not they are also trusted DaaS Users, at the touch of a button.

[00061] Such DaaS System 210 group policies can include any conventional and familiar feature of popular conventional directory services such as Microsoft Active Directory without jeopardizing the security of mission-critical and/or data-sensitive resources of the corporate LAN 202. As mentioned above, this is done using two of the novel features of the directory service architecture embodiment described by FIG. 3 that are missing from the embodiment described by FIG. 2, namely the one-way trust connection 418 and the designation of the directory service domain controller 416 as having primacy over the directory service domain controller 304. These features are next described in more detail.

[00062] First, the directory service domain controller 304 in the virtual room 102 interoperates with the directory service domain controller 416 on the corporate network 202 by establishing a one-way trust connection 418 in which the virtual room 210 on the cloud is in the trusting domain, and the controlled access infrastructure 104 on the corporate network 202 is in the trusted domain. With the appropriate credentials, a trusted DaaS User who is authenticated with the directory service domain controller 416 on the corporate network 202 (i.e., the trusted domain) can also access resources made available to that user by that domain controller 416 when using a virtual desktop 108 in the cloud-based virtual room 102 (i.e., the trusting domain). This can happen in part because under the one-way trust connection 418, users authenticated by the directory service domain controller 416 (being in the trusted domain of the one-way trust connection) can roam to the DaaS System 210, become trusted DaaS Users, and be served by the directory service domain controller 304 (being in the trusting domain of the one-way trust connection) under a transitive trust established between the trusted domain directory service domain controller 416 and the trusting domain directory service domain controller 304. Such trusted DaaS Users can access the resources of both the DaaS System 210 via the DaaS-based directory service domain controller 304, and the resources of the LAN 202 via a combination (as discussed below) of the DaaS-based directory service domain controller 304and the LAN-based directory service domain controller 416. Because of the one-way trust connection however, the converse is not true; untrusted DaaS Users in the DaaS System 210 (i.e., the trusting domain) who have only been authenticated by the directory service domain controller 304, are unable to access resources controlled by the directory service domain controller 416 (i.e., the trusted domain) because of the operation of the one-way trust connection 418. This secures the mission-critical and/or data-sensitive resources of the DaaS Organization such as databases and applications 118a, from access by unauthorized DaaS Users.

[00063] Second, as mentioned above, the directory service domain controller 416 on the DaaS Organization's corporate LAN 202 (i.e., the trusted domain), is designated as the primary server for directory services (i.e., the primary domain controller) as compared to the directory service domain controller 304 in the virtual room 102 on the DaaS System/cloud 210 (i.e., the trusting domain). The primacy of the DaaS Organization's LAN-based directory service domain controller 416 over its DaaS-System-based directory service domain controllers 304, means that the DaaS Organization's LAN-based directory service domain controller 416 can control the DaaS-System-based directory service domain controllers 304 to provide directory services to a user that has been properly authenticated in the LAN-based directory service domain controller's domain (a trusted user), even when that user is roaming to a DaaS System and thus becomes a trusted DaaS User. When such a trusted user roams to a DaaS System and becomes a trusted DaaS User, she interacts with a DaaS-based directory domain controller. That DaaS- based directory domain controller 304 in turn provides directory services to the trusted DaaS User by interacting with the primacy-status LAN-based directory domain controller 416, which itself has the required directory services information to provide the trusted DaaS User many of the same directory services she enjoys when logged into the corporate LAN. This means the authenticated LAN-based user (the trusted user) can access the same directory services as a DaaS User (i.e., when logged into the DaaS System) that she enjoys when directly logged into the LAN. And the trusted DaaS User can enjoy these feature-rich directory services that require access to resources on the LAN 202 without requiring the sensitive information of the LAN-based directory domain controller to be replicated on the DaaS System, and thus without that information being made accessible to other DaaS Users of the DaaS System who are not authenticated by the LAN-based directory domain controller.

[00064] The primacy of the directory service domain controller 416 also means that trusted users can be managed primarily as corporate LAN 202 users (e.g., Windows users, if the LAN 202 is operating a Microsoft Active Directory Service domain controller), even when they operate as DaaS Users on virtual desktops 108 in the cloud-based virtual room 102. Such trusted DaaS Users can enjoy feature-rich directory services they enjoyed on the corporate LAN, including group policies, when logged into the DaaS System. Specifically, when a trusted user roams to the DaaS System and becomes a trusted DaaS User, that user can enjoy user-focused group policies while on the DaaS System, as a result of the operation of the LAN-based directory service domain controller 416 and its control over the DaaS-based directory service domain controller 304. This is because the primacy-status conventional directory service domain controller 416 (a) already has the information required to support directory services for that LAN user, including user-focused group policies for that LAN user (since that user was already authenticated by the directory services domain controller 416), (b) can access directory service domain controller 304 over the one-way trust connection and (c) has primacy over the directory service domain controller 304. This means that when a trusted user roaming to a DaaS System 210 requests a directory service such as access to a group policy, from directory service domain controller 304, that request can be passed to the directory service domain controller 416 that has primacy, and that already has access to mission-critical and/or data-sensitive information to implement the group policy. The directory service domain controller 416 can process the request, and decide on a response, and pass that response back to the directory service domain controller 304. All of this can occur without the directory service domain controller 304 accessing any resources on the corporate LAN 202 in contravention of the one-way trust connection 418. Therefore, when a trusted LAN user operates as a DaaS User on a virtual desktops 108 in the cloud-based virtual room 102, her resource access can be managed using the conventional directory controller 416 and all the mission-critical and/or data-sensitive information inside it, without providing an untrusted DaaS User access to that same mission- critical and/or data-sensitive information.

[00065] One skilled in the art will note that group policies and other non-mission-critical and non-data-sensitive information from the LAN 202 (including such information from the primary-status directory service domain controller 416) must be transferred to and kept at the DaaS-based directory service domain controller 304 to enable trusted DaaS Users to access mission-critical and/or data-sensitive resources of the DaaS Organization such as databases and applications 118a. Such non-mission-critical and non-data-sensitive information can tell the DaaS-based directory service domain controller 304 when and how to interact with the primacystatus directory service domain controller 416, when the former receives a request to access a resource that turns out to be mission-critical and/or data-sensitive (such as access to any of databases and applications 118a, including any critical and confidential files). One skilled in the art will understand that such a transfer of non-mission-critical and non-data-sensitive information can occur as soon as a the trusted DaaS User logs into the DaaS System, when the trusted DaaS User actually requests access to a mission-critical and/or data-sensitive resource, or at other times.

[00066] The combination of these two features— the one-way trust connection 418 and the primacy of the conventional directory service domain controller 416 on the corporate LAN 202 over the directory service domain controller 304 in the virtual room 102— results in a very powerful directory service capability for trusted users that extends to the DaaS System 210 without exposing the mission-critical and/or data-sensitive resources of the DaaS Organization such as databases and applications 118a.

[00067] As stated above, this powerful directory service capability cannot be made available to untrusted users that are unknown to the primacy-status conventional directory services controller 416. This is because (a) the conventional directory services controller 416, which has access to the sensitive information required for such powerful directory service capabilities, does not have any information about such an untrusted DaaS User since that user would never have been authenticated by that domain controller 416; and (b) the directory service domain controller 304, which is the only domain controller with information about untrusted DaaS Users, is starved of this sensitive information because it cannot access the resources it needs to provide that directory service itself due to the operation of the one-way trust connection 418. This means that group policies cannot be supported for such untrusted DaaS Users.

[00068] It is to be noted that by providing primacy to the conventional directory service domain controller 416 on the DaaS Organization's corporate LAN 202, the domain controller 416 can also serve as the central authentication point for all users, whether trusted or untrusted. This means that all DaaS Users operating in the virtual room 210 can be centrally and securely managed using the domain controller 416 under this second embodiment. And this can happen without providing any access from the DaaS System to the mission-critical and/or data-sensitive resources of the DaaS Organization such as databases and applications 118a, to users that are not properly credentialed and authenticated in the domain of the LAN-based directory services controller 416, because of the one-way-trust connection 418.

[00069] In the embodiment of FIG. 3, the group policies of trusted DaaS Users can be changed, at the touch of a button. More generally, any directory service of a trusted user that can be changed when they are logged into the corporate LAN 202, can also be changed when they are logged into the virtual room 102. This is due to the conventional directory service domain controller's 416 (i.e., the domain controller with primacy) ability to facilitate such changes, and because that directory service domain controller 416 would already have information about such a trusted LAN user (since that user would have already been authenticated by the directory service domain controller 416 as a LAN 202 user, before he roamed to the virtual room 102 on the DaaS System 210). The domain controller 416 can therefore make any changes to a directory service of a trusted DaaS User, even when the user is logged into the DaaS System 210, at the touch of a button.

[00070] Under this second embodiment, group policies of the DaaS Organization can be either virtual-desktop-focused for untrusted users, or user-focused for trusted users. When the group policies are virtual-desktop-focused, they are able to provide centralized management of all virtual desktops 108 in a virtual room 102, as a collective, thus providing all the benefits realized under the first embodiment of the present disclosure. When the group policies are user-focused, they are able to additionally support centralized management of individual trusted users, and therefore can vary from trusted DaaS User to trusted DaaS User, or as between a trusted DaaS User authenticated by the LAN-based directory service domain controller 416 and an untrusted user.

[00071] The ability of this second embodiment to offer user-focused group policies for individualized trusted users enables a DaaS User who is authenticated by the directory service domain controller 416 on the DaaS Organization's corporate LAN 202 to maintain his identity as a user in that LAN-based domain, even when he has roamed to a virtual desktop on a cloudbased DaaS System 202 to operate in a cloud-based domain as a DaaS User. For example, a corporate LAN 202 user whose group policy settings provided her access to certain files on the DaaS Organization's corporate LAN 202 can carry those group policy settings with her when she roams to a virtual desktop 108 on the cloud-based DaaS System 210 and can therefore access the exact same file from the corporate LAN 202. More generally, the embodiment of FIG. 3 enables a trusted user to enjoy the same desktop user experience, whether logged into a virtual desktop 108 as a DaaS User or a client computer running a desktop application on the corporate LAN 202. Essentially, user settings for that DaaS User are inherited from the trusted domain (LAN 202), allowing that DaaS User to enjoy a seamless experience while using the DaaS in the trusting domain (DaaS System 210). That is, in such a case, the trusted user's group policy settings can be inherited from the directory service domain controller 416 in the trusted domain, allowing the user to enjoy a seamless experience while transitioning from a traditional desktop on corporate LAN 202 to a virtual desktop 106 on the DaaS System 210 (where the user becomes a trusted DaaS User).

[00072] The embodiment's ability to offer this additional user-focused group policy type, also enables heretofore unachievable controls by an administrator over trusted DaaS Users using user-focused group policies. For example, the administrator can make group policy changes that impact a trusted user, both when that user is operating in the DaaS Organization corporate LAN 202 using a conventional client computer, and when that same user is operating a virtual desktop 108 in the virtual room 102 as a DaaS User. An IT administrator can further override any directory settings applied to a DaaS User when operating a virtual desktop 108 in virtual room 102 using group policy settings applied to that same user when she was operating a client computer on the DaaS Organization's corporate LAN 202.

[00073] An additional capability enabled by the architecture of this second embodiment, and by user-focused group policies in particular, is the association of a security stack with an individual trusted user depending on whether she is operating in the DaaS Organization's corporate LAN 202 as a conventional user of directory services or in a virtual desktop 108 in the cloud-based virtual room 102 as a DaaS User of directory services. This makes it possible to use a directory service or group policy to lock out a particular user from client computers in the DaaS Organization's corporate LAN 202 while enabling that same user to have access to a DaaS in the virtual room 102, or vice versa.

[00074] An additional capability enabled by the architecture of this second embodiment is that a software module can run credentialed as a user in either the DaaS Organization's corporate LAN 202, or in the DaaS Organization's virtual room 102, drawing on different permissions and resources depending on where the software is running. [00075] An additional capability enabled by the architecture of this second embodiment is enablement of more granular audit logs that track users even as they move back and forth between the DaaS Organization's corporate LAN 202 premises and the virtual desktops in cloudbased virtual rooms 102.

[00076] Since group policies associated with untrusted DaaS Users (i.e., users not from the trusted domain) do not permit access to any directory service domain controller (and its mission critical and data sensitive information) maintained by the DaaS Organization on its corporate LAN 202 (i.e., trusted domain), the mission-critical and/or data-sensitive resources of the DaaS Organization are still isolated from a security perspective from untrusted DaaS Users. Therefore, support for all the features associated with user-focused group polices for trusted DaaS Users do not cause increased security risks for the DaaS Organization with respect to untrusted DaaS Users. The secure flow of data from a virtual room 102 to a DaaS Organization's LAN 202, over the one-way trust connection 418 through a secure gateway, remains materially unaltered from implementations of virtual rooms that used a zero-trust connection.

[00077] It is to be understood that other aspects of the embodiments presented will become readily apparent to those skilled in the art from the preceding detailed description, wherein various embodiments are shown and described. The drawings and the detailed description should be regarded as illustrative in nature and are not restrictive.

[00078] Although the present disclosure has been described with respect to specific embodiments thereof, these embodiments are merely illustrative, and not restrictive of the present disclosure. Rather, the description is intended to describe illustrative embodiments, features and functions in order to provide a person of ordinary skill in the art context to understand the present disclosure without limiting the present disclosure to any particularly described embodiment, feature or function. While specific embodiments of, and examples for, the present disclosure are described herein for illustrative purposes only, various equivalent modifications are possible within the spirit and scope of the present disclosure, as those skilled in the relevant art will recognize and appreciate. As indicated, these modifications may be made to the present disclosure in light of the foregoing description of illustrated embodiments of the present disclosure and are to be included within the spirit and scope of the present disclosure. Thus, while the present disclosure has been described herein with reference to particular embodiments thereof, a latitude of modification, various changes and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances, some features of embodiments of the present disclosure will be employed without a corresponding use of other features without departing from the scope and spirit of the present disclosure as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit of the present disclosure.

Claims

34 [00079] What is claimed is:

1. A Desktop-as-a-Service (DaaS) System running on a cloud computing facility that provides a directory service, and that can interoperate with an associated controlled access infrastructure system running on a corporate LAN, the DaaS System comprising: an interface to a zero-trust connection between the DaaS System and the controlled access infrastructure system; and, a virtual room comprising a plurality of virtual desktops, a first directory service domain controller for implementing and managing a group policy that can be applied to the virtual desktops, and a zero-trust access module for implementing the zero-trust connection. wherein the group policy can be operated and managed by the domain controller without requiring access to any resource in the controlled access infrastructure system.

2. The DaaS System of claim 1 wherein the group policy is scoped to the virtual room such that the group policy is applied to each of the plurality of virtual desktops.

3. The DaaS System of claim 2 wherein the group policy can be used to change any feature of all of the plurality of virtual desktops, with the invocation of a single command.

4. The DaaS System of claim 3 wherein said feature of the virtual desktops can control any one the appearance, composition, or maintenance of the virtual desktops.

5. The DaaS System of claim 3 further comprising a first resource in the DaaS System, and wherein the DaaS group policy prevents all the virtual desktops from accessing the first resource.

6. The DaaS System of claim 1 further comprising a second directory service domain controller that functions as a backup to the first directory service domain controller. 35

7. A Desktop-as-a-Service (DaaS) System that provides a directory service, and that can interoperate with an associated LAN, said LAN having a LAN-based directory service domain controller that has path information for accessing a LAN-based resource according to a first group policy, said first group policy specifying whether to prevent or permit access to the LANbased resource by a first authenticated user of the LAN, the DaaS System comprising: an interface to a one-way trust connection between the DaaS System and the controlled access infrastructure system in which the DaaS System is the trusting domain and the controlled access infrastructure system is the trusted domain; a virtual room comprising a first virtual desktop that is assigned to the first user when the first user is logged into the DaaS System, a one-way trust access module for implementing the one-way trust connection, and a cloud-based directory service domain controller for accepting a first request by the first user to access the LAN-based resource when the first user is assigned to the first virtual desktop; wherein the LAN-based directory service domain controller has primacy over the cloud-based directory service domain controller, such that the first request is granted or rejected by the LAN-based directory service domain controller according to the first group policy; wherein the DaaS System does not have said path information; and, wherein the one-way trust connection is operable to prevent users authenticated by the DaaS System but not by the LAN, from accessing said path information.

8. The DaaS System of claim 7 wherein the virtual room further comprises a second virtual desktop that is assigned to a second user that is amongst the users authenticated by the DaaS System but not by the LAN; and, the cloud-based directory service domain controllerfurther has path information for accessing a cloudbased resource using a second group policy that specifies whether to prevent or permit access to the cloud-based resource by the second user, and further accepts a second request by the second user to access the cloud-based resource when the second user is assigned to the second virtual desktop.

9. The DaaS System of claim 8 wherein the LAN-based directory service domain controller controls access to the LAN-based resource using a third group policy that is different from the first group policy; the virtual room further comprises a third virtual desktop that is assignable to a third user that is authenticated by the LAN, wherein the cloud-based directory service domain controller further accepts a third request by the third user to access the LAN-based resource when the third user is assigned to the third virtual desktop; and, wherein the LAN-based directory service domain controller has primacy over the cloud-based directory service domain controller, such that the third request is granted or rejected by the LANbased directory service domain controller according to the third group policy.

10. The DaaS System of claim 9 wherein the first group policy can be extended to a fourth authenticated LAN user.

11. The DaaS System of claim 10 wherein the first group policy can be changed by the invocation of a single command.

12. The DaaS System of claim 9 wherein the first group policy and the third group policy are each a user-focused group policy, and the LAN-based resource is a file.

13. The DaaS System of claim 8 wherein: the virtual room further comprises a fourth virtual desktop that is assigned to a fourth user that is amongst the users authenticated by the DaaS System but not by the LAN; and the cloud-based directory service domain controllerfurther has path information for accessing the cloudbased resource using the second group policy, and further accepts a fourth request by the fourth user to access the cloud-based resource when the fourth user is assigned to the fourth virtual desktop.

14. The DaaS System of claim 13 wherein the second group policy can be changed by the invocation of a single command.

15. The DaaS System of claim 9 wherein the second group policy is a virtual-desktop-focused group policy, and the cloud-based resource is a desktop appearance.

16. The DaaS System of claim 7 wherein the LAN further comprises a LAN-based desktop assigned to the first user, and the first group policy is applied to the LAN-based desktop when the first user is logged into the LAN.

17. The DaaS System of claims 7-16 further comprising a backup to the cloud-based directory service domain controller.