Remote desktop service authentication method, computer equipment and computer storage medium
By establishing a dynamic association mapping between user identity and virtual address in a remote desktop virtualization environment, the problems of identity theft and permission confusion caused by virtual IP address reuse are solved, and the accurate binding of user identity and virtual address and behavior traceability are realized.
Patent Information
- Application Number
- CN202512059358.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-31
- Publication Date
- 2026-03-17
AI Technical Summary
In remote desktop virtualization environments, the reuse of virtual IP addresses leads to user identity theft and disordered access control, making it difficult to manage and trace user behavior.
By sending a login message containing user identity information and target virtual address information to the authentication device during the user login phase, a dynamic association mapping is established to ensure the real-time binding of the virtual address with the current user identity, and the association relationship is updated when the address is reused.
It achieves precise binding between user identity and virtual address, ensuring the accuracy of permission management and behavior traceability, avoiding permission confusion and identity confusion, and improving the accuracy of user identity management and traffic traceability capabilities.
Smart Images

Figure CN121690847A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of remote access control, specifically to a remote desktop service authentication method, computer equipment, and computer storage medium. Background Technology
[0002] Windows Server (Winserver) is an enterprise-grade server operating system platform developed by Microsoft, designed to run and protect enterprise applications, services, and workloads. Winserver provides remote desktop services, enabling users to deliver desktops and applications to a Winserver server as if they were using their own computer.
[0003] In a remote desktop virtualization environment, multiple users can connect to the same application server (Winserver) through different sessions and share the same IP address. This makes it impossible to distinguish user identities by IP address, making user behavior management difficult. To address this, the application server provides a DHCP (Dynamic Host Configuration Protocol) service to assign virtual IPs to sessions, and uses an Access Controller (AC) device to manage user access behavior and user permissions, as well as the virtual IPs they use.
[0004] However, virtual IPs can be reused and reclaimed, meaning the same virtual IP can be assigned to different users successively. For example, if user A logs off, their virtual IP is reclaimed by DHCP, and subsequently, user B's session happens to obtain that same virtual IP, resulting in user identity theft. In this case, the AC device still considers the virtual IP to belong to user A, which could lead to user B mistakenly enjoying user A's network access permissions, i.e., disordered access control; or user B's behavior could be incorrectly recorded under user A's name, affecting the traceability of user internet activity. Summary of the Invention
[0005] This application provides a remote desktop service authentication method, computer device, and computer storage medium. It establishes a dynamic association mapping based on the correspondence between the user identity and the virtual address of the current session, and updates the association relationship according to the new login message. This avoids identity confusion caused by virtual address reuse, avoids user permission management disorder, and also helps to trace the user's online behavior.
[0006] A first aspect of this application provides a remote desktop service authentication method, the method being applied to an authentication device connected to an application server; the method includes:
[0007] The application server receives a user login message, which encapsulates the identity information of the first user and the target virtual address information allocated by the application server for the remote desktop session of the first user.
[0008] Parse the user login message to obtain the identity information of the first user and the target virtual address information;
[0009] Establish an association between the identity information of the first user and the target virtual address information;
[0010] Based on the association, the session traffic of the remote desktop session corresponding to the target virtual address information is associated with the identity information of the first user.
[0011] A second aspect of this application provides a remote desktop service authentication method, the method being applied to an application server, the application server being connected to an authentication device; the method includes:
[0012] In response to the login request of the first user, a remote desktop session with the first user is created, and the corresponding target virtual address information is assigned to the remote desktop session of the first user;
[0013] The identity information of the first user is collected from the login request, and the identity information of the first user and the target virtual address information are encapsulated into a user login message.
[0014] The authentication device sends the user login message to the authentication device, so that the authentication device establishes an association between the identity information of the first user and the target virtual address information based on the user login message, and associates the session traffic of the remote desktop session corresponding to the target virtual address information with the identity information of the first user based on the association.
[0015] A third aspect of this application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the methods of the first or second aspect described above.
[0016] A fourth aspect of this application provides a computer storage medium storing instructions that, when executed on a computer, cause the computer to perform the methods described in the first or second aspect.
[0017] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:
[0018] By sending a login message containing user identity information and target virtual address information to the authentication device during the user login phase, the authentication device can obtain the mapping relationship between the user identity and virtual address in the current session in real time and establish a dynamic association mapping based on this relationship. When a virtual address is reused (e.g., a second user reuses the same virtual address after the first user logs out), the authentication device will update the association relationship according to the new login message, ensuring that the same virtual address is always bound to the identity of the currently logged-in user in different session phases.
[0019] This dynamic binding mechanism completely avoids the identity confusion problem caused by virtual address reuse in traditional solutions: on the one hand, when processing session traffic, the authentication device will accurately associate the traffic with the current user identity by querying the real-time association mapping, and will not erroneously attribute the cause due to the historical binding records of virtual addresses; on the other hand, the permission control policy will also be executed based on the currently valid identity-address association relationship, ensuring that the second user can only enjoy the network permissions corresponding to themselves, rather than the legacy permissions of the first user, thereby realizing the accurate binding of user identity and virtual address, accurate traceability of traffic, and dynamic adaptation of permissions, effectively solving the problems of disordered permission management and difficulty in behavior traceability. Attached Figure Description
[0020] Figure 1 This is a schematic diagram of the network framework in an embodiment of this application;
[0021] Figure 2 This is a flowchart illustrating the remote desktop service authentication method in the embodiments of this application;
[0022] Figure 3 This is another flowchart illustrating the remote desktop service authentication method in this application embodiment;
[0023] Figure 4 This is another flowchart illustrating the remote desktop service authentication method in this application embodiment;
[0024] Figure 5 This is a schematic diagram of an exemplary configuration interface for the single sign-on method of the authentication device in this application embodiment;
[0025] Figure 6 This is an exemplary page diagram of the configuration page for group policy management in the embodiments of this application;
[0026] Figure 7 This is a schematic diagram of an exemplary configuration interface for a single sign-on script in this application embodiment;
[0027] Figure 8This is a schematic diagram of a computer device in an embodiment of this application. Detailed Implementation
[0028] This application provides a remote desktop service authentication method, computer device, and computer storage medium. It establishes a dynamic association mapping based on the correspondence between the user identity and the virtual address of the current session, and updates the association relationship according to the new login message. This avoids identity confusion caused by virtual address reuse, avoids user permission management disorder, and also helps to trace the user's online behavior.
[0029] Please see Figure 1 The network framework in this embodiment includes:
[0030] User terminal (PC): Represents the user's work computer or virtualization device. Users initiate connections from here to access remote applications (RemoteApp) via a browser or client.
[0031] Network switching equipment (Switch): Connects user terminals to the backend network and is responsible for Layer 2 forwarding of internal data. For example, it receives access request packets from PCs and forwards these packets to the next-hop AC device. Simultaneously, the Switch also connects to the backend server cluster (Winserver, AD, DHCP), so legitimate access traffic processed by the AC also reaches the application server through the Switch; response data returned by the application server (such as the RemoteApp screen) is also returned to the user's PC through the Switch. It ensures that all internal components are on the same Layer 2 network and can communicate with each other.
[0032] Authentication device (AC): This is a network access control device deployed on critical network paths in bridge or router mode. It is responsible for receiving user identity information from application servers and performing real-time, accurate binding of user identity, session IP, and network permissions, thereby controlling all traffic flowing to the internet.
[0033] Server cluster: This is the service provider, and it specifically includes:
[0034] Application server (Winserver): Deploys remote desktop services, is responsible for publishing RemoteApps (such as Internet Explorer), and creates an independent virtualization environment for each user session.
[0035] Active Directory (AD Server): Provides unified identity authentication and management, verifies the domain account used for user login, and executes login scripts through Group Policy. AD refers to Active Directory, a directory service in Microsoft Windows Server responsible for storing information about users, computers, groups, and other objects on the network and providing authentication and authorization services. In this embodiment, it serves as the unified management center for domain user identities.
[0036] DHCP server: Dynamically assigns a unique virtual IP address to each remote desktop session on Winserver, ensuring that different sessions do not have the same IP address.
[0037] Optionally, in actual deployment, the three roles of AD Server, DHCP Server, and Winserver can be integrated into the same physical server.
[0038] The Internet represents the external network. As the exit point, when a user needs to access external network resources (such as public websites) within a remote desktop session, the traffic path is: Winserver session → Switch → AC → Internet. The AC manages internet access behavior at this stage.
[0039] Therefore, the above architecture uses AC devices to link front-end user network access with the back-end virtualization application and identity management system consisting of Winserver, AD and DHCP servers, forming a complete and controllable remote working environment.
[0040] The following is combined with Figure 1 The network framework described herein is used to illustrate the remote desktop service authentication method in the embodiments of this application:
[0041] Please see Figure 2 One embodiment of the remote desktop service authentication method in this application includes:
[0042] 201. Receive a user login message sent by the application server, wherein the user login message encapsulates the identity information of the first user and the target virtual address information allocated by the application server for the remote desktop session of the first user;
[0043] The method in this embodiment can be applied to an authentication device connected to an application server. This application server can be configured with services such as WinServer, AD Server, DHCP Server, and Remote Desktop Services to provide remote desktop session services to users. When a first user initiates a login request through a user terminal, the application server can create a corresponding remote desktop session based on the request and assign target virtual address information (such as a virtual IP) to the session via the DHCP server. Simultaneously, the application server can collect the first user's identity information from the login request, such as domain account and user ID, and encapsulate this information along with the target virtual address information into a user login message, which is then sent to the authentication device. The authentication device, as a control node in the network, can receive this message in real time, preparing for subsequent identity and address binding.
[0044] 202. Parse the user login message to obtain the identity information of the first user and the target virtual address information;
[0045] In this step, the authentication device performs protocol parsing and field extraction on the received user login message. First, it identifies the message's encapsulation format, determining the storage location of identity information and virtual address information based on a preset communication protocol specification. Then, it extracts the first user's identity information (such as domain account "user001" and user unique identifier "ID12345") and target virtual address information (such as virtual IP "192.168.1.101") from the corresponding fields. Optionally, the extracted information can also be format-validated to ensure the integrity of the identity information and the legality of the virtual address, avoiding information loss or format abnormalities due to message transmission errors.
[0046] 203. Establish an association between the identity information of the first user and the target virtual address information;
[0047] In this step, the authentication device creates or updates an identity-address mapping table in its local storage module, writing the extracted first user identity information and target virtual address information as key-value pairs into the table. For example, when the first user identity information is the domain account "user001" and the target virtual address is "192.168.1.101", a new record will be added to the mapping table: "user001 → 192.168.1.101". Simultaneously, this association will be timestamped, recording the creation time of the binding for subsequent tracking of virtual address reuse. If the target virtual address has previously been associated with another user (e.g., user A has used this address), the authentication device can first clear the old association record and then establish a new association, ensuring that the same virtual address is only bound to the currently logged-in user identity at any given time.
[0048] 204. Based on the association relationship, associate the session traffic of the remote desktop session corresponding to the target virtual address information with the identity information of the first user;
[0049] In this step, the authentication device monitors the session traffic of the remote desktop session corresponding to the target virtual address information in real time. When the session traffic is detected, it determines the first user identity information corresponding to the session traffic by querying the locally stored identity-address mapping table, and then associates the session traffic with the first user identity information. For example, when a session with the target virtual address "192.168.1.101" initiates a request to access the Internet, the authentication device captures the request traffic, finds the user associated with the address as "user001" through the mapping table, and then adds the identity identifier "user001" to the header or metadata of the traffic data packet, thereby binding the traffic with the user identity and facilitating the tracing of the user's Internet access behavior.
[0050] Optionally, the authentication device can also implement preset access control policies on session traffic based on this association, such as allowing "user001" to access specific Internet resources, restricting its access to sensitive websites, or allocating bandwidth to its traffic, to ensure that the network access permissions of different users are accurately matched with their own identities and avoid permission confusion caused by virtual address reuse.
[0051] The following will be discussed in the preceding text. Figure 2 Based on the illustrated embodiments, embodiments of this application will be described in further detail. Please refer to [link to relevant documentation]. Figure 3 Another embodiment of the remote desktop service authentication method in this application includes:
[0052] 301. In response to the login request of the first user, create a remote desktop session with the first user and assign the corresponding target virtual address information to the remote desktop session of the first user;
[0053] The method in this embodiment can be applied to an application server, which can be connected to an authentication device. The application server can be configured with services such as WinServer, AD Server, DHCP Server, and Remote Desktop Services to provide remote desktop session services to users. When a first user initiates a login request through a user terminal (such as a PC), the login request may include the first user's domain account, password, and other identity credentials. The application server can create an independent remote desktop session for the first user based on the remote desktop service. This session can generate an isolated running space within the application server's virtualization environment, ensuring that session data from different users does not interfere with each other.
[0054] Meanwhile, the DHCP service in the application server can dynamically assign a unique target virtual address to the remote desktop session based on the currently available virtual IP address pool, such as "192.168.2.5", and feed the assignment result back to the application server. The application server then binds the target virtual address to the first user's remote desktop session, so that the session can communicate over the network through the virtual address during operation.
[0055] 302. Collect the identity information of the first user from the login request, and encapsulate the identity information of the first user and the target virtual address information into a user login message;
[0056] In this step, the application server can read the first user's identity information from the first user's login request, such as domain account, user ID, and user group. Then, the application server encapsulates the collected first user identity information and the assigned target virtual address information according to a preset message format to generate a user login message. The message encapsulation can use a fixed field structure; for example, the header fields contain metadata such as message type identifier and message length, while the data fields sequentially store the user identity information type, identity information content, virtual address type, and virtual IP address content, ensuring that the authentication device can accurately parse out the key information.
[0057] 303. Send the user login message to the authentication device so that the authentication device establishes an association between the identity information of the first user and the target virtual address information based on the user login message, and associates the session traffic of the remote desktop session corresponding to the target virtual address information with the identity information of the first user based on the association.
[0058] In this step, the application server sends the encapsulated user login message to the authentication device through a pre-configured communication interface (such as a TCP / IP protocol port). Upon receiving the message, the authentication device can proceed according to... Figure 2 In the embodiment, steps 202 to 204 first parse the message to extract the identity information of the first user and the target virtual address information, then establish a dynamic association between the two in the local storage module, and perform identity tagging and permission control on the session traffic corresponding to the target virtual address based on the association.
[0059] Therefore, based on Figure 2 The illustrated embodiments and Figure 3In the illustrated embodiment, during the user login phase, the application server sends a login message encapsulating user identity information and target virtual address information to the authentication device. This enables the authentication device to obtain the correspondence between the user identity and the virtual address in the current session in real time and establish a dynamic association mapping based on this correspondence. When a virtual address is reused (e.g., a second user reuses the same virtual address after the first user logs out), the authentication device updates the association relationship according to the new login message, ensuring that the same virtual address is always bound to the identity of the currently logged-in user in different session phases.
[0060] This dynamic binding mechanism completely avoids the identity confusion problem caused by virtual address reuse in traditional solutions: on the one hand, when processing session traffic, the authentication device will accurately associate the traffic with the current user identity by querying the real-time association mapping, and will not erroneously attribute the cause due to the historical binding records of virtual addresses; on the other hand, the permission control policy will also be executed based on the currently valid identity-address association relationship, ensuring that the second user can only enjoy the network permissions corresponding to themselves, rather than the legacy permissions of the first user, thereby realizing the accurate binding of user identity and virtual address, accurate traceability of traffic, and dynamic adaptation of permissions, effectively solving the problems of disordered permission management and difficulty in behavior traceability.
[0061] The following is based on Figure 2 and Figure 3 The illustrated embodiments further describe in detail the remote desktop service authentication method of this application. Please refer to [link to relevant documentation]. Figure 4 Another embodiment of the remote desktop service authentication method in this application includes:
[0062] 401. The authentication device receives a single sign-on configuration operation input by the user, wherein the single sign-on configuration operation is used to configure the authentication device to listen for messages sent by the application server;
[0063] 402. The authentication device listens for user login messages sent by the application server based on the single sign-on configuration.
[0064] 403. In response to the single sign-on configuration operation, the authentication device downloads the configuration data of the single sign-on program;
[0065] 404. The application server obtains the configuration data of the single sign-on program, and downloads and installs the single sign-on program according to the configuration data.
[0066] In this embodiment, the authentication device can be configured with a single sign-on (SSO) method. SSO means that a user can access multiple mutually trusted application systems with a single login, without having to repeatedly enter their account and password. The administrator of the authentication device can input relevant operation instructions to configure the SSO method. The authentication device then downloads the configuration data of the SSO program based on the administrator's configuration. This SSO program configuration data can be configured by the administrator to the Active Directory Service (AD server) domain of the application server. Thus, the application server can download and install the SSO program based on the configuration data, and perform a series of actions such as user identity and session IP collection, packet encapsulation, and sending to the authentication device when a user logs in.
[0067] In this context, an Active Directory Service domain refers to a logical group built by Active Directory Services in Microsoft Windows Server, used for centralized management of resources such as user accounts, computer devices, and security policies within the domain. In this embodiment, the ADserver domain serves as the storage carrier for single sign-on (SSO) configuration data. It can synchronize SSO configuration data (including program files, installation parameters, and message sending rules) issued by the authentication device to all application servers running Remote Desktop Services within the domain, ensuring consistent SSO configuration across all application servers.
[0068] For example, Figure 5 This document illustrates an exemplary configuration interface for a single sign-on (SSO) method on an authentication device. In this interface, users can check the "Enable Domain Single Sign-On" box to configure the authentication device's login method as SSO. Subsequently, administrators can click the "Download Domain Single Sign-On Program" link, causing the authentication device (AC device) to download the SSO program configuration data. This configuration data can be deployed to the Active Directory (AD) server domain. The application server then obtains the SSO program file and installs the SSO program. This program will subsequently be placed on the application server and automatically invoked by the domain login script, responsible for collecting and reporting user identity and IP address information.
[0069] In addition, administrators can set a "shared key" which is used to encrypt messages communicating between AC devices and the Active Directory service domain of the application server, ensuring the security of identity information transmission.
[0070] Furthermore, administrators can select "Automatically distribute and execute specified login scripts to obtain login information via domain," which will then apply to the AC device. The AC device will monitor the network, receive encrypted identity messages from the domain environment, decrypt and verify them, and update the user's online status. The task of collecting and reporting identity information is handled by the AD service. The AC device trusts and relies on the AD domain's inherent "Group Policy" mechanism, waiting for the AD domain to automatically trigger the single sign-on procedure via the distributed login script when a user logs in. This process involves collecting the user's identity and session IP, encrypting it, and sending it to the AC, among other actions.
[0071] For example, the AC device downloads a single sign-on package, which includes the core executable file logon.exe. On Active Directory domain services, the logon.exe program file provided by the AC is placed in the shared directory of the domain policy. Subsequently, using the "Group Policy Management" tool, the default domain policy is edited, and a script (instruction) is added to "User Logon Scripts" to specify that logon.exe should run automatically at login, and key parameters are configured for it, such as the AC's IP address (ac_ip) and the previously set shared key.
[0072] Furthermore, assuming that when a domain user (e.g., test1) successfully logs into a remote desktop session, the AD domain's group policy mechanism will automatically execute this login script, silently starting logon.exe in the background. This program then collects the current username, domain name, and session virtual IP, encrypts them using a shared key to obtain an encrypted message, and sends it directly to the designated AC device.
[0073] Therefore, by configuring single sign-on, users only need to complete authentication once within a remote desktop session to seamlessly access integrated services such as WinServer, AD, and DHCP on the application server. This eliminates the need to repeatedly enter usernames and passwords across different service modules, significantly simplifying the login process and improving the efficiency of remote work. Simultaneously, due to the single sign-on configuration, the AD service becomes a trusted service on the AC device. User identity information and session IP address information are sent from the AD service to the AC device, automatically enabling user login on the AC device. This avoids secondary authentication on the AC device side, further reducing operational complexity and achieving single sign-on when using remote desktop services.
[0074] 405. In response to the login request of the first user, the application server creates a remote desktop session with the first user and assigns the corresponding target virtual address information to the remote desktop session of the first user;
[0075] In this embodiment, the application server can configure a remote desktop service to create relatively isolated remote desktop sessions for users' remote access. Specifically, when configuring the remote desktop service, the application server can configure an Active Directory service, create an Active Directory service domain based on the Active Directory service, and add the computer identifier corresponding to the application server to the remote desktop service security group of the Active Directory service domain, thereby granting the application server permission to access the remote desktop service. Furthermore, the application server can deploy the remote desktop service based on this permission and publish a remote desktop application (RemoteApp) based on the remote desktop service.
[0076] For example, a WinServer can be deployed, where the Active Directory (AD) server, DHCP server, and Remote Desktop Services can all be configured on the same WinServer. The AD Server acts as a domain controller, and a domain (e.g., named test.com) can be created. This establishes a unified identity management system, and test users test1 and test2 can be created later to test the system's feasibility. All users will log in using domain accounts, which is the foundation for centralized authentication and policy distribution.
[0077] For example, when configuring Remote Desktop Services, administrators can use the "Add Roles and Features" wizard in WinServer's "Server Manager" to select roles and services such as "Remote Desktop Web Access," "Remote Desktop Session Host," and "Remote Desktop Connection Agent" under "Remote Desktop Services," and specify the Active Directory domain as the authorization and authentication source to complete the deployment of Remote Desktop Services.
[0078] Application server administrators can also log in to WinServer using a domain administrator account to configure it, such as adding the WinServer's computer identifier (e.g., computer account) to the RDS Remote Access Servers group in the Active Directory domain, enabling WinServer to access remote desktop services. The RDS Remote Access Servers group is a pre-defined security group in WinServer Remote Desktop Services (RDS), whose member servers have permission to provide remote desktop session connections and can receive remote desktop service-related security policies and configuration information from the Active Directory domain.
[0079] Adding the application server's computer identity to the WinServer Remote Desktop Services security group is necessary because, without this step, even if Remote Desktop Services is installed and running on WinServer, domain users may be unable to successfully connect to the server's Remote Desktop Services through domain authentication due to the lack of formal access permissions granted to the computer account at the Active Directory (AD) domain level. Furthermore, communication related to Remote Desktop Services (especially authentication and authorization queries with the AD domain controller) may be denied. Therefore, this step ensures that Remote Desktop Services itself can function correctly based on domain identity. This is the starting point for all subsequent operations (such as creating sessions, assigning IP addresses, and triggering login scripts), with the goal of authorizing the WinServer to provide remote access services within the domain with a legitimate identity.
[0080] Subsequently, administrators can publish RemoteApp programs through the "Remote Desktop Service Manager". For example, commonly used office software, business system clients, browser clients, etc. can be packaged into RemoteApp. When the first user initiates a login request through the user terminal, these programs can be directly called in the remote desktop session without the need to install them on the local terminal. This ensures the consistency of the application environment and reduces the resource consumption of the local terminal.
[0081] Simultaneously, the application server can install and configure a DHCP service to create a scope (e.g., containing a virtual IP address of 192.168.58.124 for testing). The key function of this service is to dynamically assign an independent virtual IP address to each subsequent remote desktop session, giving each session a unique network identifier.
[0082] The WinServer application server, acting as the remote desktop session host, can have the "Remote Desktop Services" role installed and deployed. Subsequently, the application (such as Internet Explorer) is published as a RemoteApp, and the "Remote Desktop IP Virtualization" feature is enabled via Group Policy, set to "per session" mode. "Per session" mode means that Remote Desktop Services assigns a unique virtual IP address to each independent remote desktop session. This virtual IP address is only valid for the duration of the current session. When the session ends (e.g., user logs out, timeout disconnection), the corresponding virtual IP address is released and can be reassigned to a new session.
[0083] In this mode, even if the same user initiates multiple remote desktop connections on the same application server, each connection session will obtain a different virtual IP address, thus achieving session-level network isolation and avoiding traffic confusion or permission overreach issues caused by IP address reuse between different sessions. Therefore, this ensures that each independent session created by a user connecting to RemoteApp can obtain a unique virtual IP address from the DHCP server.
[0084] Therefore, after the application server publishes a remote desktop application based on the remote desktop service, users within the domain can connect to the remote desktop application through their terminals. For example, when the first user initiates a login request through their domain account in the Active Directory Service domain (AD server domain), the application server can create a remote desktop session with the first user, assign the target virtual address information to the first user's remote desktop session, and run the remote desktop application that the first user wants to access in the first user's remote desktop session.
[0085] 406. The application server collects the identity information of the first user from the login request based on the single sign-on program, and encapsulates the identity information of the first user and the target virtual address information into a user login message;
[0086] 407. The application server sends the user login message to the authentication device;
[0087] After deploying the single sign-on (SSO) procedure, the application server can collect the first user's identity information from the user's login request based on the SSO procedure, and encapsulate the first user's identity information and target virtual address information into a user login message and send it to the authentication device. This SSO procedure can be triggered by a script, which can be pre-configured in the application server.
[0088] Specifically, the application server can obtain the configuration information of the single sign-on script associated with the single sign-on program. This single sign-on script is used to trigger the execution of the single sign-on program. In the group policy configuration of the target domain where the application server resides, the single sign-on script can be added to the target domain according to its configuration information. This allows the single sign-on script to take effect on the application server running remote desktop services in the target domain based on the group policy configuration, and triggers the execution of the single sign-on program when a user logs into the target domain.
[0089] The domain where the application server resides refers to the logical management unit built by Active Directory Service, i.e., the AD server domain mentioned above. This domain integrates multiple application servers, user terminals, and network devices into a collaborative environment through centralized account management, security policy distribution, and resource access control.
[0090] The configuration information for a single sign-on script can include the script name, script parameters, and other configuration information related to the single sign-on script. The script name is a unique name used to identify the single sign-on script, such as "logon.exe", which points to the single sign-on program that the script will trigger. The script parameters refer to the key information that needs to be passed when triggering the single sign-on program, such as the IP address of the authentication device, the shared key, and other additional control parameters. These parameters will be executed along with the script to ensure that the single sign-on program can complete the collection of identity information and the sending of messages according to the preset rules.
[0091] The group policy configuration for the target domain where the application server resides can be, for example: Figure 6 The Group Policy Management configuration page shown can be accessed by opening "Windows Administrative Tools" on the computer and selecting the "Group Policy Management" option. On the "Group Policy Management" configuration page, add the test accounts test1 and test2 to the security filters in the "Default DomainPolicy" directory to apply the single sign-on script configuration in the Group Policy to these two test accounts. Specifically, the administrator can click the "Add" button in the "Security Filters" area of the page, enter the domain account names of test1 and test2, and complete the selection. The system will automatically verify whether these two accounts exist in the current Active Directory domain. After successful verification, they will be added to the security filter list.
[0092] The "Default Domain Policy" directory refers to the Global Group Policy Object (GPO) created by default in the Active Directory domain. Its scope covers all users and computer devices within the entire domain, serving as the core carrier for unified configuration management within the domain environment. In this embodiment, associating the single sign-on script with the "Default Domain Policy" directory ensures that all application servers running remote desktop services within the domain automatically execute the script upon user login, eliminating the need for repeated configuration on individual servers.
[0093] Furthermore, right-clicking the "Default Domain Policy" directory and selecting the "Edit" option will launch the "Group Policy Management Editor" page. Therefore, when adding a single sign-on script to the target domain's Group Policy, the application server can access the target domain's "User Configuration → Windows Settings → Scripts (Logon / Logoff)" node through the "Group Policy Management Editor" page, click the "Add" button under the "Logon" tab, select the pre-placed single sign-on script in the domain shared directory in the pop-up dialog box, and enter the configured script parameters in the "Script Parameters" field to complete the binding between the script and the Group Policy. After binding, the Group Policy will synchronize the single sign-on script to all application servers running Remote Desktop Services within the domain. When any domain user logs into these application servers via a Remote Desktop session, the Group Policy will automatically trigger the script to execute, thereby starting the single sign-on process.
[0094] For example, Figure 7 This document shows an exemplary configuration interface for a single sign-on script. In this interface, the administrator can configure information such as the script name (e.g., "logon.exe") and script parameters. Specific script parameters can include the IP address (ac ip) of the authentication device (e.g., "192.168.58.1"), the shared key (e.g., "123456"), and other additional control parameters (e.g., en _runAl=0), etc.
[0095] Therefore, through Group Policy configuration and the binding of the Single Sign-On (SSO) script, when a domain user (e.g., test1) initiates a login request via a remote desktop session and completes Active Directory (AD) domain authentication, Group Policy automatically calls the preset SSO script during the session startup phase. At this time, the script silently starts the logon.exe program, carrying pre-configured authentication device IP address, shared key, and other parameters. This program immediately collects the currently logged-in user's identity information (including username test1 and domain name test.com) and the virtual IP address corresponding to the remote desktop session (e.g., 192.168.58.124). It then uses the shared key to encrypt this information, generating a user login message conforming to the AC device's receiving format. Finally, logon.exe sends the encrypted message over the network to the AC device at the specified IP address, completing the synchronous transmission of identity information and providing a basis for subsequent access permission verification.
[0096] The above method avoids introducing additional manual configuration steps into the single sign-on process of remote desktop services. Through the automated triggering mechanism of Group Policy, it ensures that the single sign-on script executes accurately when a user logs into the domain, fundamentally eliminating the problem of missed identity information collection or failed message transmission due to human error. Simultaneously, the preset shared key encryption method in the script parameters effectively prevents user identity information and session IP addresses from being illegally stolen or tampered with during transmission, ensuring the security of the identity authentication process.
[0097] Furthermore, this design based on group policy and script linkage also supports flexible adjustments to single sign-on rules. If the IP address of the authentication device needs to be changed or the shared key needs to be updated, the administrator only needs to modify the script parameters in the group policy, without having to redeploy the entire single sign-on program, which greatly improves the maintainability and scalability of the system.
[0098] 408. The authentication device parses the user login message to obtain the identity information of the first user and the target virtual address information;
[0099] 409. The authentication device establishes an association between the identity information of the first user and the target virtual address information;
[0100] 410. The authentication device associates the session traffic of the remote desktop session corresponding to the target virtual address information with the identity information of the first user based on the association relationship;
[0101] Upon receiving a user login message, the authentication device can parse the message to extract the first user's identity information (e.g., domain username test1, domain test.com) and target virtual address information (e.g., 192.168.58.124), and establish a one-to-one correspondence between the two, storing them in a local identity-IP mapping table. This mapping table uses a key-value pair structure, with the user's identity information as the unique key and the virtual IP address as the corresponding value, supporting fast query and update operations. For example, when the session virtual IP of user test1 changes to 192.168.58.125, the mapping table will automatically overwrite the original associated record, ensuring real-time information.
[0102] After establishing the association, the authentication device can bind the identity of subsequent remote desktop session traffic based on this mapping table. Specifically, the authentication device can analyze the IP layer and transport layer information in the network traffic using Deep Packet Inspection (DPI) technology, identify data packets carrying target virtual address information, and then match the corresponding first user identity information by querying the identity-IP mapping table. Finally, the session traffic is associated with the domain account of user test1. This labeling remains effective throughout the traffic processing. Whether a user is accessing internal business systems, downloading files, or transferring data, the authentication device can accurately identify the user identity to which the traffic belongs. This provides a core basis for subsequent access control, traffic auditing, and abnormal behavior detection, such as generating audit logs containing user identity, virtual IP, access time, and internet behavior, facilitating administrator traceability and analysis.
[0103] Furthermore, in some optional implementations, if another user (such as a second user) initiates a login request after the first user logs out of their remote desktop session, the application server can respond to the second user's login request, create a remote desktop session with the second user, and allocate target virtual address information for the second user's remote desktop session. Then, the application server can collect the second user's identity information from the second user's login request and encapsulate the second user's identity information and target virtual address information into the second user's login message.
[0104] The second user's login message can be sent to the authentication device. The authentication device then parses the second user's login message to obtain the second user's identity information and target virtual address information. It then updates the previously recorded association between the first user's identity information and target virtual address information to the association between the second user's identity information and target virtual address information. Afterwards, based on the association between the second user's identity information and target virtual address information, the authentication device can associate the session traffic of the remote desktop session corresponding to the target virtual address information with the second user's identity information.
[0105] Therefore, the authentication device can update the identity-IP mapping table in real time according to the dynamic changes of the session, ensuring that the user identity information corresponding to each virtual IP address is always up-to-date and avoiding identity confusion caused by session switching.
[0106] For example, when user test1 actively logs out of the remote desktop session, the application server will immediately release the virtual IP address 192.168.58.124 it occupies and put it back into the DHCP scope's allocatable address pool. If user test2 initiates a login request at this time, the application server will assign it the released virtual IP address and trigger a single sign-on script to collect test2's identity information and send it to the authentication device. The authentication device will then update the association record corresponding to 192.168.58.124 in the mapping table from test1 to test2, ensuring that subsequent traffic to this virtual IP can be accurately associated with user test2.
[0107] This dynamic update mechanism enables efficient reuse of virtual IP addresses and ensures the accuracy and real-time nature of identity association, providing effective technical support for traffic management in scenarios with concurrent access by multiple users within the domain.
[0108] In summary, the embodiments of this application solve the problem of user permission confusion. By combining the Active Directory (AD) domain login script and the Single Sign-On (SSO) program, it ensures that each user session can accurately authenticate online when obtaining an independent IP address, thus avoiding user permission confusion. Secondly, it eliminates the need for large-scale modifications or customized development of virtualization services and network egress authentication devices; only simple configuration on the application server, combined with DHCP and AD domain services, is required, greatly simplifying the management process and reducing implementation costs. It can provide solutions for user authentication and internet behavior tracking for various projects using WinServer remote desktop virtualization.
[0109] The computer device in the embodiments of this application is described below. Please refer to [link / reference]. Figure 8 One embodiment of the computer device in this application includes:
[0110] The computer device 800 may include one or more central processing units (CPUs) 801 and a memory 805, in which one or more applications or data are stored.
[0111] The memory 805 can be volatile or persistent storage. The program stored in the memory 805 can include one or more modules, each module including a series of instruction operations on the computer device. Furthermore, the central processing unit 801 can be configured to communicate with the memory 805 and execute the series of instruction operations in the memory 805 on the computer device 800.
[0112] The computer device 800 may also include one or more power supplies 802, one or more wired or wireless network interfaces 803, one or more input / output interfaces 804, and / or one or more operating systems, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.
[0113] The central processing unit 801 can perform the aforementioned... Figures 2 to 4 The operations performed by the authentication device or the application server in the illustrated embodiments will not be described in detail here.
[0114] This application also provides a computer storage medium, one embodiment of which includes: the computer storage medium storing instructions, which, when executed on a computer, cause the computer to perform the aforementioned... Figures 2 to 4 The operations performed by the authentication device or the application server in the illustrated embodiments.
[0115] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0116] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.
[0117] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0118] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0119] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
Claims
1. A remote desktop service authentication method, characterized in that, The method is applied to an authentication device, which is connected to an application server; the method includes: The application server receives a user login message, which encapsulates the identity information of the first user and the target virtual address information allocated by the application server for the remote desktop session of the first user. Parse the user login message to obtain the identity information of the first user and the target virtual address information; Establish an association between the first user's identity information and the target virtual address information; Based on the association, the session traffic of the remote desktop session corresponding to the target virtual address information is associated with the identity information of the first user.
2. The method according to claim 1, characterized in that, Before receiving the user login message sent by the application server, the method further includes: The system receives a single sign-on configuration operation input by the user, which is used to configure the authentication device to listen for messages sent by the application server. Based on the single sign-on configuration, the system listens for user login messages sent by the application server. In response to the single sign-on configuration operation, the configuration data of the single sign-on program is downloaded. The configuration data of the single sign-on program is used to configure the application server so that the application server installs the single sign-on program according to the configuration data of the single sign-on program, encapsulates the identity information of the first user and the target virtual address information into the user login message based on the single sign-on program, and sends the user login message to the authentication device.
3. The method according to claim 1, characterized in that, After the first user logs out of their remote desktop session, the method further includes: The application server receives a user login message from the second user, which encapsulates the identity information of the second user and the target virtual address information allocated by the application server for the remote desktop session of the second user. Parse the second user's login message to obtain the second user's identity information and the target virtual address information; The association between the first user's identity information and the target virtual address information is updated to the association between the second user's identity information and the target virtual address information; Based on the association between the second user's identity information and the target virtual address information, the session traffic of the remote desktop session corresponding to the target virtual address information is associated with the second user's identity information.
4. A remote desktop service authentication method, characterized in that, The method is applied to an application server, which is connected to an authentication device; the method includes: In response to the login request of the first user, a remote desktop session with the first user is created, and the corresponding target virtual address information is assigned to the remote desktop session of the first user; The identity information of the first user is collected from the login request, and the identity information of the first user and the target virtual address information are encapsulated into a user login message. The authentication device sends the user login message to the authentication device, so that the authentication device establishes an association between the identity information of the first user and the target virtual address information based on the user login message, and associates the session traffic of the remote desktop session corresponding to the target virtual address information with the identity information of the first user based on the association.
5. The method according to claim 1, characterized in that, The step of collecting the first user's identity information from the login request and encapsulating the first user's identity information and the target virtual address information into a user login message includes: Obtain the configuration data of the single sign-on program, which is used to process user login requests; Download and install the single sign-on program according to its configuration data; Based on the single sign-on program, the identity information of the first user is collected from the login request, and the identity information of the first user and the target virtual address information are encapsulated into a user login message.
6. The method according to claim 5, characterized in that, The method further includes: Obtain the configuration information of the single sign-on script associated with the single sign-on program, the single sign-on script being used to trigger the single sign-on program to run; In the group policy configuration of the target domain where the application server is located, the single sign-on script is added to the target domain according to the configuration information of the single sign-on script, so that the single sign-on script takes effect on the application server running remote desktop service in the target domain based on the group policy configuration, and triggers the execution of the single sign-on program when the user logs into the target domain.
7. The method according to claim 1, characterized in that, The step of creating a remote desktop session with the first user and assigning corresponding target virtual address information to the first user's remote desktop session includes: Configure Active Directory service, create an Active Directory service domain based on the Active Directory service, and add the computer identifier corresponding to the application server to the Remote Desktop Services security group of the Active Directory service domain so that the application server can obtain the permission to access the Remote Desktop Services. Deploy remote desktop services based on the aforementioned permissions, and publish remote desktop programs based on the remote desktop services; When a login request is received from the first user through the domain account of the Active Directory service domain, a remote desktop session with the first user is created, the target virtual address information is assigned to the first user's remote desktop session, and the remote desktop program is run in the first user's remote desktop session.
8. The method according to claim 1, characterized in that, After the first user logs out of their remote desktop session, the method further includes: In response to the login request of the second user, a remote desktop session with the second user is created, and the target virtual address information is assigned to the remote desktop session of the second user; Collect the second user's identity information from the second user's login request, and encapsulate the second user's identity information and the target virtual address information into the second user's user login message; The authentication device sends a login message of the second user to the authentication device, so that the authentication device updates the association between the identity information of the first user and the target virtual address information to the association between the identity information of the second user and the target virtual address information based on the login message of the second user.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 3 or 4 to 8.
10. A computer storage medium, characterized in that, The computer storage medium stores instructions that, when executed on the computer, cause the computer to perform the method as described in any one of claims 1 to 3 or 4 to 8.
Citation Information
Patent Citations
Cloud virtual desktop applied control system and method for web service level and function
CN102820999A
Scalable addressing mechanism for virtual machines
CN108351798A
Dedicated sub-network for virtual private network (VPN) clients
CN114556868A
Scalable addressing mechanism for virtual machines
US20170142234A1
