A terminal domain joining method and system based on a non-Kerberos protocol

Abstract

This invention provides a terminal domain joining method and system based on a non-Kerberos protocol, relating to the field of data communication technology and applied to a domain management platform. The platform includes a client and a server. The client is deployed on the target terminal. The method includes: sending a domain joining request to the server; the server responding to the domain joining request and obtaining administrator login information from the request; the server generating domain joining credentials based on the administrator login information and sending them to the client; the client receiving the domain joining credentials and encrypting them to obtain encrypted domain joining credentials; when the client receives a login request from a target user, the client performing certificate verification with the server based on the encrypted domain joining credentials to obtain the target verification result; and authorizing the target user to log in to the target terminal based on the verification result. This invention solves the technical problem of insufficient identity authentication security caused by the use of the Kerberos protocol in the prior art, and effectively improves identity authentication security.

Description

Technical Field

[0001] This invention relates to the field of data communication technology, and in particular to a terminal domain joining method and system based on a non-Kerberos protocol. Background Technology

[0002] With the deepening of information technology and enterprise digital transformation, centralized and secure terminal management and identity authentication systems have become a core component of enterprise IT infrastructure. Traditional domain control systems have long dominated this field, providing an effective management framework for large organizations through unified policy management, user authentication, and device control. However, under the wave of information technology application innovation and operating system diversification, especially against the backdrop of the country encouraging key areas to achieve independent control of software and hardware, Windows-centric domain control architecture is facing severe challenges in terms of compatibility, security, and adaptability.

[0003] Current mainstream traditional domain control systems primarily rely on the Kerberos protocol for authentication and domain joining mechanisms. In practical applications, the domain joining process for terminals based on non-Kerberos protocols essentially uses Kerberos tickets as credentials, while user login is authenticated via the Kerberos protocol. This centralized ticket distribution and verification mechanism forms the cornerstone of traditional domain management systems, but it also becomes a major bottleneck to their security. Specifically: On the one hand, Kerberos tickets are inherently vulnerable to forgery and replay attacks. If the initial credentials used during domain joining are not adequately protected during transmission or storage, they can easily be intercepted or brute-forced, allowing unauthorized terminals to access the domain network. On the other hand, the Kerberos authentication process involves multiple stages of ticket exchange; compromise at any stage can lead to the entire authentication system being bypassed. Furthermore, the protocol itself lacks sufficient support for scenarios such as passwordless authentication and lacks strong hardware or biometric binding factors, making it susceptible to identity spoofing. Therefore, these issues result in insufficient security for identity authentication. Summary of the Invention

[0004] To address the aforementioned shortcomings in existing technologies, the present invention aims to provide a terminal domain joining method based on a non-Kerberos protocol, which features improved identity authentication security.

[0005] The above-mentioned objective of this invention is achieved through the following technical solution: A method for terminal domain joining based on a non-Kerberos protocol, characterized in that it is applied to a domain management platform, the platform including a client and a server, the client being deployed on the target terminal, and the method comprising: The client sends a domain joining request to the server. The server responds to the domain join request and obtains the administrator login information from the domain join request; The server generates domain joining credentials based on the administrator login information and sends them to the client. The client receives the domain joining certificate and encrypts it to obtain the encrypted domain joining certificate. When the client receives a login request from the target user, it performs certificate verification with the server based on the encrypted domain-adding credentials to obtain the target verification result. Based on the target verification result, the target user is authorized to log in to the target terminal.

[0006] By adopting the above technical solution, the server generates a unique domain joining credential based on the terminal device information, and the client encrypts and stores it in conjunction with the local hardware identifier, thus achieving high-strength security protection for the domain joining process. During the user login process, a two-way certificate authentication channel is established with the server using the encrypted domain joining credential, and the dual verification of user identity and terminal device legitimacy is completed simultaneously. This effectively improves the overall security of terminal domain joining and identity authentication based on non-Kerberos protocols. At the same time, this certificate-based cross-platform authentication architecture supports unified management of different operating systems, effectively improving the compatibility and operation and maintenance efficiency of the domain controller system.

[0007] Preferably, the step of generating domain joining credentials based on the administrator login information via the server and sending them to the client includes: The server performs permission verification based on the administrator login information. If the permission verification passes, the device information of the target terminal is obtained through the server. The server, based on the device information, calls the built-in digital certificate authority to generate a domain-binding credential that is bound to the target terminal. The server sends the domain joining certificate to the client.

[0008] By adopting the above technical solution, administrator privileges are strictly verified to ensure that domain joining operations are initiated by legitimate authorized personnel, thus controlling operational security from the source. After the privilege verification is passed, the device information of the terminal is further obtained, and the built-in digital certificate authority is called to generate a domain joining credential that is uniquely bound to the hardware characteristics of the terminal. This makes the credential strongly associated with the terminal, effectively preventing the credential from being illegally transferred or misused. While simplifying the management process, the security and controllability of the domain joining process are improved.

[0009] Preferably, the step of receiving the domain joining certificate through the client and encrypting the domain joining certificate to obtain an encrypted domain joining certificate includes: The client receives the domain joining credential and obtains the local device identifier of the target terminal. The client generates encrypted parameters based on a preset fixed program key and the local device identifier. The client encrypts the domain joining credential using the encryption algorithm based on the encryption parameters to obtain the encrypted domain joining credential.

[0010] By adopting the above technical solution, after receiving the domain joining credential, the client generates dynamic encryption parameters by combining the target terminal's local device identifier and a preset fixed program key. These parameters are then used to encrypt the domain joining credential using an encryption algorithm, achieving one-to-one encryption for credential storage. Even if the encrypted credential is illegally obtained, it cannot be effectively decrypted or misused due to the lack of the corresponding local device identifier and program key. This enhances the security of the domain joining credential stored locally on the terminal and effectively resists the risks of brute-force attacks and offline attacks.

[0011] Preferably, when the client receives a login request from a target user, the client performs certificate verification with the server based on the encrypted domain-addressing credentials to obtain the target verification result, including: When the client receives a login request from the target user, it responds to the login request through the client and decrypts the encrypted domain joining credential to obtain the decrypted domain joining credential. Based on the decrypted domain encryption certificate, a two-way certificate authentication channel is established between the client and the server. The client uses the two-way certificate authentication channel to send the target user's login credentials to the server for verification and receives the target verification result from the server.

[0012] By adopting the above technical solution, during the user login process, the client first decrypts and recovers the domain joining certificate stored locally in encryption, and establishes a two-way certificate authentication channel with the server based on the decrypted valid certificate. This channel not only ensures the confidentiality and integrity of the communication link itself, but also provides strong protection for the subsequent transmission of user login credentials. At the same time, through this mechanism, while authenticating user identity, the real-time verification of the legitimacy of the terminal device is also completed, realizing dual trusted authentication of user identity and terminal device, effectively preventing the risk of unauthorized terminal access or theft or tampering of user credentials during transmission, and improving security.

[0013] Preferably, the step of sending the target user's login credentials to the server for verification via the two-way certificate authentication channel through the client, and receiving the target verification result from the server, includes: The server verifies the user's identity based on the login credentials and generates a first verification result. The server verifies the binding relationship and validity between the domain joining credential and the target terminal based on the identification information of the decrypted domain joining credential, and obtains a second verification result. The server generates the target verification result based on the first verification result and the second verification result, and sends the target verification result to the client.

[0014] By adopting the above technical solution, not only is the legitimacy of the user account password confirmed, but the terminal device is also verified to be a legitimate device authorized by the system and with a valid certificate. This fundamentally prevents the misuse of user credentials on unauthorized devices and eliminates the risk of illegal devices impersonating legitimate identities to access the system, thereby improving the security of the overall domain control environment.

[0015] Preferably, authorizing the target user to log in to the target terminal based on the target verification result includes: If the target verification result is successful, the client loads the permission policy and configuration corresponding to the target user issued by the server, and allows the target user to access the operating system of the target terminal.

[0016] By adopting the above technical solution, users are only authorized to log in and access the operating system after both their identity and terminal device have passed security verification. At the same time, the client automatically loads the personalized permission policy and system configuration that are centrally distributed by the server and match the user's role. This achieves fine-grained permission control based on identity, which not only ensures that only legitimate users can log in on authorized terminals, but also enables the user's operating environment and access permissions after logging in to follow the enterprise's unified security policy in real time and dynamically. This extends security control from the single login stage to the entire user session lifecycle, effectively improving the compliance of terminal use and the centralization of management.

[0017] Preferably, after authorizing the target user to log in to the target terminal based on the target verification result, the method further includes: The server generates a user certificate that is bound to the target user and the target terminal, and sends the user certificate to the client. The client receives the user certificate and encrypts it to obtain the encrypted user certificate. When the target user requests to log in to the third-party business system, based on the encrypted user certificate, the target user is provided with passwordless authentication for the third-party business system, wherein the third-party business system has been registered on the platform.

[0018] By adopting the above technical solution, after a user successfully logs in to the terminal, a user certificate uniquely bound to the user and the current terminal is generated and securely stored in the database after encryption. When the user subsequently accesses a third-party business system that has been registered on the platform, they can directly complete identity authentication based on this encrypted user certificate without having to enter the password again. This not only extends the strong security certificate authentication method to single sign-on and passwordless authentication scenarios, effectively solving the risk of identity spoofing in traditional passwordless login, but also ensures that authentication credentials cannot be misused on other devices through the dual binding of the user and the terminal, thus improving the user experience.

[0019] The second objective of this invention is to provide a terminal domain joining system based on a non-Kerberos protocol, which has the characteristic of improving identity authentication security.

[0020] The second objective of this invention is achieved through the following technical solution: A terminal domain joining system based on a non-Kerberos protocol, characterized in that it is applied to a domain management platform, the platform including a client and a server, the client being deployed on the target terminal, and the system comprising: The domain join request initiation module is used to send a domain join request to the server through the client; The request processing and authentication module is used to respond to the domain joining request through the server and obtain the administrator login information in the domain joining request. The domain joining credential generation and distribution module is used to generate domain joining credentials based on the administrator login information through the server and send them to the client; The credential receiving and security processing module is used to receive the domain joining credential through the client and encrypt the domain joining credential to obtain the encrypted domain joining credential. The user login verification module is used to verify the target user's login request by having the client perform certificate verification with the server based on the encrypted domain-adding credentials, and obtain the target verification result. The login authorization module is used to authorize the target user to log in to the target terminal based on the target verification result.

[0021] By adopting the above technical solutions, the domain joining request initiation module and the request processing authentication module jointly ensure the controllability and source security of the domain joining operation. The domain joining credential generation and distribution module generates a uniquely bound digital credential based on device information, establishing a trusted identity for the terminal. The credential receiving and secure processing module effectively resists the risk of credential leakage through local encrypted storage. The user login verification module uses encrypted credentials to establish a two-way certificate channel, realizing dual verification between users and devices. The login authorization module implements fine-grained permission control based on the verification results. The entire system, through modular design, organically combines certificate authentication, encrypted storage, two-way verification, and policy distribution, which not only improves the overall security of terminal domain joining and identity authentication based on non-Kerberos protocols, but also achieves unified and efficient management of multiple types of operating systems.

[0022] The third objective of this invention is to provide an electronic device that improves the security of identity authentication.

[0023] The above-mentioned objective three of this invention is achieved through the following technical solution: An electronic device includes a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described above for a terminal domain joining method based on a non-Kerberos protocol.

[0024] The fourth objective of this invention is to provide a computer-readable storage medium capable of storing corresponding programs, which facilitates the improvement of identity authentication security.

[0025] The fourth objective of this invention is achieved through the following technical solution: A computer-readable storage medium storing a computer program that can be loaded by a processor and executed by any of the preceding methods for terminal domain joining based on a non-Kerberos protocol.

[0026] In summary, the present invention has at least one of the following beneficial technical effects: 1. This invention generates a unique domain joining credential based on device information and uses local hardware identifiers for encrypted storage, thereby achieving high-strength security protection in the domain joining process. When a user logs in, a two-way certificate authentication channel is established through the encrypted credential to simultaneously complete the dual legality verification of the user's identity and the terminal device, effectively improving authentication security. It also supports unified management of different operating systems, improving the compatibility and operation and maintenance efficiency of the domain control system. 2. This invention does not rely on the Kerberos protocol. It achieves domain joining and user login for terminals based on non-Kerberos protocols through a custom certificate authentication mechanism, thereby avoiding common security risks and vulnerabilities from the root and improving the security foundation of the domain control system.

[0027] 3. This invention effectively solves the risk of identity theft in traditional passwordless authentication scenarios by automatically generating a user certificate as an identity credential after user login, thus expanding the scope of application of security authentication. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating the steps of a terminal domain joining method based on a non-Kerberos protocol provided in Embodiment 1 of the present invention.

[0029] Figure 2 This is a schematic diagram of the terminal domain joining process based on a non-Kerberos protocol, provided in Embodiment 1 of the present invention.

[0030] Figure 3 This is a schematic diagram of a user login authentication process for a terminal domain joining method based on a non-Kerberos protocol, provided in Embodiment 1 of the present invention.

[0031] Figure 4 This is a schematic diagram of a passwordless login authentication process for a terminal domain joining method based on a non-Kerberos protocol, provided in Embodiment 1 of the present invention.

[0032] Figure 5 This is a schematic diagram of bidirectional HTTPS certificate authentication communication for a terminal domain joining method based on a non-Kerberos protocol, provided in Embodiment 1 of the present invention.

[0033] Figure 6 This is a structural block diagram of a terminal domain joining system based on a non-Kerberos protocol provided in Embodiment 2 of the present invention. Detailed Implementation

[0034] This invention provides a terminal domain joining method and system based on a non-Kerberos protocol, which addresses the technical problem of insufficient identity authentication security in existing technologies. It effectively improves identity authentication security.

[0035] Traditional domain controller systems are designed for Windows systems, which severely limits their management of domestic operating systems. They struggle to achieve unified management of multiple domestic and open-source operating systems such as Windows, Kylin, UnionTech, and Linux. This necessitates enterprises deploying multiple domain controller services, each adapted to different terminals, increasing deployment costs and operational complexity. Furthermore, this leads to issues such as fragmented management, inconsistent policies, and the following security risks: 1. Traditional computer domain control systems generally rely on the Kerberos protocol to implement terminal domain joining and user login authentication based on non-Kerberos protocols. This protocol has exposed many security risks and vulnerabilities in long-term use, such as ticket forgery, man-in-the-middle attacks, and abuse of privileges, posing potential threats to enterprise information security.

[0036] 2. The Kerberos protocol lacks a secure and reliable identity credential mechanism in passwordless authentication scenarios, which makes it prone to identity theft.

[0037] 3. In the traditional process of joining a domain from a terminal based on a non-Kerberos protocol, the storage method of the domain joining credentials is not secure enough and is easily cracked by brute force, which further reduces the overall security level of the domain controller system.

[0038] Therefore, there is an urgent need for a terminal domain joining and domain control system based on a non-Kerberos protocol that breaks through the dependence on the Kerberos protocol, is compatible with multiple operating systems, and has high security, in order to solve the shortcomings of existing technologies.

[0039] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0040] It should be noted that, in the embodiments of this invention, when the relevant object information and other related data are used in specific products or technologies, permission or consent from the object is required, and the collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if the embodiments of this invention involve data related to an object, it must be obtained with the object's authorization and consent, the authorization and consent of relevant departments, and in accordance with the relevant laws, regulations, and standards of the country and region. If personal information is involved in the embodiments, the acquisition of all personal information requires the individual's consent; if sensitive information is involved, the separate consent of the information subject is required. The embodiments also need to be implemented with the object's authorization and consent.

[0041] It should be noted that the terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The implementations described in the following exemplary embodiments do not represent all implementations consistent with this disclosure.

[0042] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0043] Example 1: Please see Figure 1-5 This invention provides a method for terminal domain joining based on a non-Kerberos protocol, applied to a domain management platform. The platform includes a client and a server, with the client deployed on the target terminal. The method includes: A domain management platform refers to a terminal management and authentication platform based on a client-server architecture, used to achieve unified security control over terminals of various operating systems.

[0044] A client refers to client software deployed on the terminal side to execute local operations and policies. The client deployment method is as follows: based on the terminal operating system type (Windows 10 / 11, Kylin V10, UnionTech UOS, Ubuntu 20.04, etc.), download the corresponding version of the client installation package, and deploy it to each terminal through batch push or manual installation. After installation, the client can complete the domain joining through methods such as manual registration by the administrator or automatic registration by script.

[0045] The server-side refers to a web server application deployed on the server side to provide centralized management functions. The deployment method of the web server is as follows: deploy the server on the enterprise intranet server, configure the server hardware parameters (such as CPU ≥ 8 cores, memory ≥ 16G, storage ≥ 500G), install the operating system (supporting CentOS 7.0+, Kylin V10, Tongxin V20, etc.), deploy a database (such as MySQL 8.0) to store user information, device information, certificate data, etc., and after starting the web server, initialize the self-signed CA authority and configure parameters such as CA certificate validity period and encryption algorithm.

[0046] The target terminal refers to a computing device that intends to join or is already under the unified management scope of the domain management platform. The client is installed and running on the device, and its hardware and operating system constitute the physical and logical carrier for performing domain joining operations, accepting policy control, and performing user authentication.

[0047] It's worth noting that, through the web server + client architecture, administrators can log in to the server management backend to create group policies, such as software installation, file access permissions, and network configurations, and associate these policies with specified user groups or terminal groups. The web server can then distribute the configured policies to the corresponding terminal clients. After receiving the policies, the clients can automatically execute the policy configurations, such as installing specified software or setting file permissions. Furthermore, the clients can synchronize the policy execution status of the terminals to the server in real time. Administrators can view the policy execution results in the backend. If a policy needs to be updated, the administrator can modify it on the server and reissue it. The clients will automatically receive and overwrite the old policy, ensuring policy consistency.

[0048] It is worth mentioning that the above architecture enables full coverage management of terminals with multiple operating systems, eliminating the need to deploy multiple domain controller services, effectively reducing enterprise deployment costs and operational complexity, and ensuring the consistency of management strategies.

[0049] Step 101: Send a domain joining request to the server via the client.

[0050] A domain join request is a structured network message that includes at least the identifier of the domain the target terminal wants to join, the administrator's credentials for initiating the operation, and necessary terminal device information.

[0051] In this embodiment of the invention, the administrator enters the management address of the server, as well as their own administrator account, password, and terminal device information on the client interface of the target terminal, and sends a domain joining request containing the above-mentioned administrator login information to the server through a secure network connection via the client's built-in communication module.

[0052] Step 102: Obtain the administrator login information from the domain join request by responding to the domain join request on the server side.

[0053] Administrator login information refers to the identity authentication data used by an administrator to prove their operating authority, including but not limited to the account name and the matching password, token or other authentication factors.

[0054] In this embodiment of the invention, when the server receives a domain join request sent by the client, the platform controls the server to extract login credentials such as the administrator account and password from the domain join request, ensuring that the domain join process can continue based on accurate administrator identity information.

[0055] Step 103: The server generates domain joining credentials based on the administrator login information and sends them to the client.

[0056] Preferably, step 103 may include the following sub-steps: S11. Perform permission verification based on administrator login information via the server.

[0057] Permission verification refers to the security process by which the server verifies the authenticity of the administrator login information and checks the operation permissions after receiving a domain joining request.

[0058] It is worth mentioning that it can verify whether the administrator account and password match the authorization credentials pre-stored in the platform, and can also verify whether the administrator account has been granted the permission to initiate terminal domain joining or equivalent operations based on non-Kerberos protocols. It should be noted that this verification method can be configured according to actual needs.

[0059] In this embodiment of the invention, the platform control server first queries the record corresponding to the submitted account from the securely stored database, verifies the correctness of the password through a secure password hash comparison algorithm, and after the identity authentication is passed, it can retrieve the role permission list associated with the account to determine whether it contains the permission identifier necessary to perform the domain joining operation based on the non-Kerberos protocol. If both verifications pass, a permission verification result is generated, allowing the process to continue; otherwise, a verification failure result is generated, and the current domain joining process is terminated, thus ensuring the legality and controllability of the domain joining operation from the management source.

[0060] S12. If the permission verification passes, the device information of the target terminal is obtained through the server.

[0061] Device information refers to a set of data that can uniquely identify and describe the hardware and basic software characteristics of a target terminal, including but not limited to computer motherboard serial number, device name, MAC address, operating system type and version, etc.

[0062] In this embodiment of the invention, after the server completes the administrator permission verification and confirms that it has passed, the platform controls the server to parse and extract the device information from the received and cached domain joining request data. This eliminates the need for additional communication overhead in requesting information from the client, improving the overall efficiency of the domain joining process and ensuring the immediate availability of the data required for credential generation.

[0063] S13. Based on the device information, the server calls the built-in digital certificate authority to generate domain-adding credentials that are bound to the target terminal.

[0064] A digital certificate authority (DCA) is a software module integrated within a server that conforms to public key infrastructure standards and has the functions of issuing and managing digital certificates. Among them, a DCA is a self-signed root CA, whose core function is to issue digital certificates as trusted identity credentials to network entities based on authentication policies.

[0065] Domain joining credentials refer to a special format of digital certificate issued by a server-side digital certificate authority. It serves as a unique digital identity for a target terminal to join a domain management platform and gain recognition from the management platform. The certificate contains key information including, but not limited to, the terminal's motherboard number, device name, and domain joining time, and can be used to achieve a strong cryptographic binding between the credential and the terminal.

[0066] Once the server confirms that the permission verification has passed and that it has obtained the valid device information of the target terminal, it calls its built-in digital certificate authority to execute the certificate issuance process. The server uses the device information as the core request content for certificate signing, generates a certificate signing request according to the predetermined X.509 certificate format template and cryptographic parameters (such as key algorithm, validity period, extended fields, etc.), and uses the CA private key to perform digital signing, finally generating a standard format digital certificate.

[0067] It is worth mentioning that the specific content fields and encoding methods of the domain joining credentials can be flexibly configured according to actual security policies and management needs. For example, information such as operating system version and domain joining administrator identifier can be added to meet the auditing and control requirements in different scenarios.

[0068] In this embodiment of the invention, the platform control server, based on the device information, calls its built-in digital certificate authority to generate domain-binding credentials that are bound to the target terminal.

[0069] S14. Send the domain joining certificate to the client via the server.

[0070] In this embodiment of the invention, after the server successfully generates the domain joining certificate bound to the target terminal, the platform controls the server to encapsulate the domain joining certificate in a standard secure communication protocol response message and send it to the client through the established and authenticated communication link, thereby ensuring that the domain joining certificate can be securely and accurately delivered to the target terminal.

[0071] Step 104: Receive the domain joining certificate through the client and encrypt the domain joining certificate to obtain the encrypted domain joining certificate.

[0072] Preferably, step 104 may include the following sub-steps: S21. Receive the domain joining certificate through the client and obtain the local device identifier of the target terminal.

[0073] The local device identifier refers to the information that the client can collect from the terminal hardware or firmware to identify the physical device by calling the local interface of the operating system it is running on. Preferably, the local device identifier is the computer motherboard serial number.

[0074] In this embodiment of the invention, after the platform control client successfully receives the domain joining credential issued by the server, it performs two operations: first, it stores the received domain joining credential in a temporary security buffer; second, it calls the platform's local interface to collect the local device identifier of the current terminal in real time, and compares the device identifier information encapsulated in the domain joining credential with the local device identifier just collected in real time. If the two match, it confirms that the domain joining credential was indeed issued to the current physical device, the verification is successful, and the process continues. If they do not match, it indicates that there may be an anomaly such as credential misissue, device replacement, or transmission tampering. The client will terminate the process and report an error, effectively avoiding the phenomenon of credential impersonation and packet swapping attacks.

[0075] S22. The client generates encrypted parameters based on a preset fixed program key and the local device identifier.

[0076] A pre-defined fixed program key refers to a set of fixed cryptographic keys that are determined and embedded in the program code or security configuration during the client software compilation or deployment phase. This key does not depend on runtime generation or user input and is used as the basic key material for the client to perform local encryption operations.

[0077] Encryption parameters refer to a set of dynamic data generated by specific cryptographic operations on a preset fixed program key and a local device identifier.

[0078] It is worth mentioning that the encryption parameters will serve as the actual encryption key, initial vector, or salt value required when performing encryption operations on the domain-adding credentials. Their purpose is to ensure that the encryption process is bound to specific terminal hardware, so that the encryption result has the characteristic of one key per device.

[0079] In this embodiment of the invention, after the client completes the local reception of the domain addition certificate and the verification of the device identifier, the platform controls the client to read the preset fixed program key from the secure storage area and cryptographically combine it with the local device identifier collected in real time. The combination method can be concatenation, hash operation, or calculation based on the key derivation function (such as PBKDF2) to generate encryption parameters strongly associated with the current terminal hardware.

[0080] S23. The client encrypts the domain joining certificate using encryption algorithms based on encryption parameters to obtain the encrypted domain joining certificate.

[0081] In this embodiment of the invention, after generating encryption parameters bound to the current terminal hardware, the platform control client uses the national cryptographic SM4 algorithm to perform symmetric encryption on the domain-adding credential temporarily stored in secure memory, using the encryption parameters as the key or initial vector required for the encryption process. During the encryption process, the encrypted domain-adding credential is generated and written to the target terminal's local database or protected storage area (path is configurable), thus completing the process of the terminal accessing the domain control platform.

[0082] It is worth mentioning that after the encrypted storage is completed, the client can send a message to the server indicating that the domain has been successfully joined. After receiving the feedback, the server updates the terminal's status to "domain joined" and displays the domain joined status indicator on the client's user interface.

[0083] Step 105: When the client receives the login request from the target user, it performs certificate verification with the server based on the encrypted domain-addressed credentials to obtain the target verification result.

[0084] Preferably, step 105 may include the following sub-steps: S31. When the client receives the login request from the target user, it responds to the login request through the client and decrypts the encrypted domain joining credential to obtain the decrypted domain joining credential.

[0085] A login request is a structured instruction generated by the login interface or platform login manager after a user enters their domain account and password on the terminal login interface, requesting identity authentication. The request includes, but is not limited to, user account name, hashed or encrypted password credentials, and optional session identifiers.

[0086] The decrypted domain-adding credential refers to the credential obtained by the client using the same or paired cryptographic parameters and algorithms used in the previous encryption to reverse the operation on the encrypted domain-adding credential.

[0087] Understandably, when a target user attempts to log in on a domain-joined terminal, they enter their username and password on the operating system login screen or a unified login portal managed by the client, triggering the login operation. The client, acting as the controller of the login process, monitors and captures this login request in real time. Then, the client accesses the terminal's local protected storage area, reads the encrypted domain-joining credentials previously stored during the domain-joining phase, and performs a decryption operation based on these credentials. Specifically: The client obtains the key materials required for decryption, which consist of two parts: first, a preset fixed program key embedded in the client program or security configuration; and second, a local device identifier collected in real time from the current terminal hardware. These two parts of information are combined according to preset cryptographic rules to generate a decryption key that is strictly bound to the current terminal. The SM4 decryption algorithm is then used to decrypt the encrypted domain-adding certificate using the generated decryption key. If decryption is successful, the decrypted domain-adding certificate is output. This domain-adding certificate contains the terminal's unique identifier and the validity information of the certificate itself.

[0088] The preset cryptographic rules include, but are not limited to, hashing after concatenation, or directly using them as input to the key derivation function.

[0089] It is worth mentioning that if there are problems such as mismatched device identifiers, corrupted stored data, or incorrect keys, the decryption will be deemed to have failed, the client will terminate the login process, record the error log, and return a login failure message to the user.

[0090] In this embodiment of the invention, when the client receives a login request from a target user, the platform controls the server to respond to the login request, extract the encrypted domain joining credential from the local database, and decrypt the encrypted domain joining credential using the SM4 decryption algorithm to obtain the decrypted domain joining credential, effectively preventing security risks such as credential leakage, identity impersonation, and data tampering.

[0091] S32. Based on the decrypted domain-adding credentials, establish a two-way certificate authentication channel between the client and the server.

[0092] A two-way certificate authentication channel refers to a secure communication link established between a client and a server based on the TLS / SSL protocol. Its core feature is that both parties need to present and verify each other's digital certificates, thereby achieving two-way identity verification between the client and the server at the communication layer.

[0093] Specifically, the client first initiates a TLS connection request to the server's preset management port, declaring its client certificate during the handshake negotiation. The server responds with its own server certificate. The client uses a locally pre-installed trusted root certificate to verify the certificate's signature validity, expiration date, and identity information, ensuring the connection is to a legitimate domain controller server and preventing server impersonation. The server then requests proof of identity from the client. The client sends its decrypted domain encryption credentials as its client certificate to the server, simultaneously signing the random challenge during the handshake process using the private key paired with that certificate to prove its identity. After receiving the client's certificate, the server performs multi-layered verification: First, it verifies the signature validity, validity period, and revocation status of the client certificate using the built-in CA certificate; second, it extracts the embedded terminal device identification information from the certificate and compares it with the terminal registration information stored in the server's database to confirm the strong binding relationship between the certificate and the terminal device; finally, it verifies the signature sent by the client using the certificate's public key to complete the proof of private key possession. After all verifications are passed, both parties securely negotiate a symmetric encryption key for this session based on an asymmetric encryption algorithm, thus formally establishing a two-way certificate authentication channel.

[0094] In this embodiment of the invention, after the platform control client successfully obtains the decrypted domain joining certificate, it establishes a two-way certificate authentication channel with the server. This not only ensures the encryption and integrity of the transmitted data, but more importantly, it ensures that only terminals holding legitimate certificates can establish a trusted connection with the server, effectively defending against man-in-the-middle attacks and unauthorized access.

[0095] S33. Using a two-way certificate authentication channel, the client sends the target user's login credentials to the server for verification and receives the target verification result from the server.

[0096] Login credentials refer to the combination of information that a user enters on the login screen to prove their identity. They typically include the user's username and corresponding password, with the password being hashed locally on the client before being transmitted.

[0097] The target verification result refers to the final conclusion generated by the server after comprehensively verifying the user's identity and terminal device. It is usually a successful or unsuccessful verification, and may be accompanied by detailed authorization information or error reasons.

[0098] Understandably, once the two-way certificate authentication channel is successfully established, the platform will control the client to encrypt and transmit the target user's login credentials to the server through this secure channel, and wait for the server's verification response. After receiving the credentials, the server will execute multi-layered verification logic, as follows: S1. The server verifies the user's identity based on the login credentials and generates the first verification result.

[0099] The first verification result refers to the result obtained by the server in matching and verifying the account and password provided by the user, which is used to confirm whether the user is a legitimate user registered on the platform and has the correct password.

[0100] In this embodiment of the invention, after the server receives the login credentials sent by the client through a secure channel, it first queries the corresponding user record in the platform's user database based on the received user account. The server compares the password hash value stored in the database that is bound to the user account with the password hash value transmitted by the client. If the two match and the user account is active, not expired, and not locked, the user's identity is determined to be legitimate, and a first verification result of success is generated; otherwise, a first verification result of failure is generated, ensuring that only legitimate users with the correct password can pass the identity verification.

[0101] S2. The server verifies the binding relationship and validity between the domain joining credential and the target terminal based on the identification information of the decrypted domain joining credential, and obtains the second verification result.

[0102] The second verification result refers to the result obtained by the server in verifying the legality, validity, and binding relationship between the decrypted domain-adding credentials used by the client in two-way authentication and the requesting login terminal.

[0103] In this embodiment of the invention, the server extracts key identification information from the domain joining certificate, such as the certificate serial number, the terminal motherboard number embedded in the subject, and the device name. Then, the server queries the platform's device management database to verify the following: whether the certificate serial number was issued by the platform's CA and is within its validity period; whether the device identifier embedded in the certificate is completely consistent with the terminal device identifier recorded in the database that has been successfully joined to the domain; whether the terminal device's status in the database is that it is joined to the domain and is online or active. The server can also check whether the domain joining time, administrator identifier, and other information recorded in the certificate's extended fields match the records. Only when all checks pass, does the server confirm that the domain joining certificate is valid and correctly bound to the terminal device currently requesting login, and generate a second verification result of success; otherwise, it generates a second verification result of failure, ensuring that the login request originates from a legitimate terminal device that has been authorized by the platform and whose identity has not been impersonated.

[0104] S3. The server generates the target verification result based on the first and second verification results, and sends the target verification result to the client.

[0105] In this embodiment of the invention, the server integrates the first verification result and the second verification result. Only when both the first verification result and the second verification result are successful will the server generate the final target verification result as successful login authorization. The server can also generate and attach information such as the user's access token, permission list, and effective group policy identifier, which are encapsulated in the response message. If either the first verification result or the second verification result fails, the server generates the target verification result as failed login authorization, which can include a specific reason for failure. After generating the target verification result, the platform controls the server to encrypt and return the result to the client through the established two-way certificate authentication channel. This achieves dual trusted authentication of the user's identity and the terminal device, fundamentally preventing the threat of legitimate users logging in on unauthorized devices or illegal devices impersonating legitimate identities.

[0106] Step 106: Based on the target verification result, authorize the target user to log in to the target terminal.

[0107] Preferably, step 106 may include the following sub-steps: S41. If the target verification result is successful, the client loads the permission policy and configuration corresponding to the target user issued by the server, and allows the target user to access the target terminal's operating system.

[0108] Permission policies and configurations refer to the set of control rules that the server predefines and centrally manages based on enterprise security standards and user roles. These rules include, but are not limited to: system resources that users can access, operation permissions that can be executed, interface personalization settings, security audit rules, and task scripts that need to be executed automatically after login.

[0109] In this embodiment of the invention, when the client receives the login authorization success result returned by the server, it begins to execute the terminal login authorization process. The platform controls the client to first parse the user permission and policy identification information attached to the response, and through the established two-way secure channel, request or directly receive the detailed permission policy and configuration data corresponding to the user from the server, and load and parse it in the local secure environment. The client dynamically adjusts the user's access permissions on the terminal according to the policy content. After the policy is implemented, the client notifies the underlying operating system to allow the user session to be established, and the user can then log in and use the terminal.

[0110] It is worth mentioning that if the target verification result fails, the platform control client will reject the target user's login request and not allow them to access the operating system. It can record detailed login failure logs, including the reason for failure, timestamp, user account, terminal device identifier, and other information, and report them to the server through a secure channel so that the administrator can audit and investigate the security incident.

[0111] Based on the above feasible embodiments, in order to enable login to the platform even in passwordless authentication scenarios, the following specific steps can be included after the target user successfully logs into the target terminal: Step 107: Generate a user certificate that is bound to the target user and the target terminal through the server, and send the user certificate to the client.

[0112] A user certificate is a digital certificate issued by a certificate authority. It is used to uniquely identify a user and can replace traditional passwords for authentication in specific scenarios. The certificate content includes, but is not limited to, metadata such as user identity information, the identifier of the bound terminal device, and the validity period, and is signed by the platform's CA private key.

[0113] In this embodiment of the invention, after a target user successfully logs into the target terminal using an account and password, the platform control server will automatically trigger the user certificate generation process. The server first constructs a certificate issuance request based on the user's identity identifier and the device identifier of the currently logged-in terminal. Then, the server calls its built-in digital certificate authority to issue a unique user certificate that is strongly bound to the currently logged-in terminal and transmits it to the client.

[0114] Step 108: Receive the user certificate through the client and encrypt it to obtain the encrypted user certificate.

[0115] An encrypted user certificate refers to a secure storage format obtained by encrypting a plaintext user certificate using a key derived from the user's password after the client receives it.

[0116] In this embodiment of the invention, after the platform control client receives the user certificate issued by the server, it obtains the password used by the target user when logging in. Using this password as the basic key material, it combines a preset salt value or key derivation function to generate a symmetric key for encryption. Then, the client uses the derived key to encrypt the user certificate using encryption algorithms such as the Chinese national cryptographic standard SM4, generating an encrypted user certificate. After encryption, the client securely stores the encrypted user certificate in the terminal's local database or a protected storage area and establishes an association index with the user account, ensuring the storage security of the user certificate. Even if the storage medium is illegally accessed, a valid plaintext certificate cannot be directly obtained.

[0117] Step 109: When a target user requests to log in to a third-party business system, the system provides passwordless authentication to the third-party business system based on the encrypted user certificate. The third-party business system has already been registered on the platform.

[0118] Passwordless authentication refers to the process by which users can complete identity verification without entering a password, using strong credentials such as digital certificates issued by the platform.

[0119] Third-party business systems refer to various application systems within an enterprise that have been integrated and registered with this domain control platform, such as OA, CRM, ERP, etc.

[0120] In this embodiment of the invention, when a target user accesses a registered third-party business system on the same terminal, the business system initiates an authentication request to the client of this platform through an integrated authentication plugin or standard protocol. After obtaining user authorization, the client retrieves the encrypted user certificate associated with the user from local storage and decrypts the certificate using the password-derived key verifiable by the user's current login session, recovering the plaintext user certificate. Then, according to the secure interaction protocol agreed upon with the business system, the client submits the user certificate or the authentication token generated based on the certificate to the business system through a secure channel. After receiving the credential, the business system forwards it to its server for verification. The server verifies the validity of the user certificate, the binding relationship, and the authenticity of the signature. After successful verification, the server confirms the user's legitimate identity to the business system, and the business system establishes a user session accordingly, allowing the user to log in without a password. Throughout the entire process, the user does not need to enter a password again, which not only improves the user experience but also avoids the risk of identity theft in traditional passwordless authentication through the hardware-bound certificate mechanism, achieving a balance between security and convenience.

[0121] To facilitate understanding of the specific applications in passwordless scenarios, the following is a detailed interaction flow between the client, the business system, and the server: Administrators need to register the third-party business systems to be integrated on this platform in advance. The platform will assign a unique application identifier to the business system and generate a corresponding asymmetric key pair. The APPID and business public key need to be configured by the administrator in the corresponding module of the business system to establish its trusted identity within this domain control system.

[0122] When a user who has successfully logged into a domain account starts or accesses the business system on the terminal, the authentication process is triggered. The business system client will digitally sign the authentication request, including parameters to prevent replay attacks such as timestamps and random numbers, based on the pre-configured APPID and business public key and in accordance with the predefined single sign-on protocol specifications. The client will then call the client deployed on this terminal through the local security interface.

[0123] Upon receiving a call request, the client first uses the pre-stored business private key corresponding to the business system's APPID in the platform to verify the legality of the request signature, thereby confirming the authenticity and trustworthiness of the business system initiating the request. After successful verification, the client retrieves and decrypts the encrypted user certificate bound to the user from its local protected storage using the user session key, recovering its plaintext. Then, the client constructs a secure data structure named usercode, which contains the unique identifier of the user certificate, key attribute information, and other necessary authentication elements. To ensure the confidentiality and integrity of this information during transmission, the client encrypts the usercode using the business system's public key and attaches its own digital signature. Finally, the client returns this encrypted and signed usercode to the business system client that initiated the request.

[0124] After receiving the usercode, the client system performs a local re-signing process on it. This double-signed usercode is then used as authentication credentials to call the server's dedicated verification interface via a secure network channel. Upon receiving the request, the server first decrypts the usercode using its private key, extracts the user certificate information, and performs multi-layered verification: first, verifying the validity of the user certificate itself; second, confirming whether the binding relationship between the certificate and the terminal device from which the request originated remains valid; and third, verifying the authenticity of the client signature and the business system signature attached to the usercode, ensuring that the credentials have not been tampered with during transmission and that their source is trustworthy. Once all verifications are successful, the server generates a response containing user identification, role attributes, and other information, and securely returns it to the business system.

[0125] After receiving the verification success information and user identity data returned by the server, the business system confirms that the current user's identity is legitimate and valid. Based on this, the business system establishes an authenticated session state for the user, allowing the user to directly access system functions without entering a password, thereby achieving a secure and convenient passwordless single sign-on experience.

[0126] Example 2: Please see Figure 6 This invention provides a terminal domain joining system based on a non-Kerberos protocol, applied to a domain management platform. The platform includes a client and a server, with the client deployed on the target terminal. The system includes: The domain join request initiation module 101 is used to send a domain join request to the server through the client.

[0127] The request processing and authentication module 102 is used to obtain the administrator login information in the domain joining request by responding to the domain joining request on the server side.

[0128] The domain joining credential generation and distribution module 103 is used to generate domain joining credentials based on the administrator login information via the server and send them to the client.

[0129] The credential receiving and security processing module 104 is used to receive domain joining credentials through the client and encrypt the domain joining credentials to obtain encrypted domain joining credentials.

[0130] The user login verification module 105 is used to verify the target user's login request by having the client perform certificate verification with the server based on the encrypted domain-addressed credentials, and obtain the target verification result.

[0131] The login authorization module 106 is used to authorize the target user to log in to the target terminal based on the target verification result.

[0132] Since the above is a system corresponding to a terminal domain addition method based on a non-Kerberos protocol, its implementation principle is the same as that of a terminal domain addition method based on a non-Kerberos protocol. For the sake of convenience and brevity, those skilled in the art can clearly understand that the specific working process of the system and modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0133] Example 3: An electronic device according to an embodiment of the present invention includes: a memory and a processor, wherein the memory stores a computer program; when the computer program is executed by the processor, the processor performs a terminal domain joining method based on a non-Kerberos protocol as described in any of the above embodiments.

[0134] The memory can be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. The memory has storage space for program code used to perform any of the method steps described above. For example, the storage space for program code may include individual program codes for implementing the various steps in the methods described above. This program code can be read from or written to one or more computer program products. These computer program products include program code carriers such as hard disks, compact discs (CDs), memory cards, or floppy disks. The program code may be compressed, for example, in a suitable form. When run by a computing processing device, this code causes the computing processing device to perform the various steps in the methods described above.

[0135] Example 4: This invention provides a computer-readable storage medium storing a computer program thereon, which, when executed, implements the terminal domain joining method based on a non-Kerberos protocol according to any of the above embodiments.

[0136] Those skilled in the art will 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.

[0137] 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 through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0138] 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.

[0139] Furthermore, the functional units in the various embodiments of the present invention 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.

[0140] 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 the present invention, 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 the present invention. 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.

[0141] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A terminal domain joining method based on a non-Kerberos protocol, characterized in that, Applied to a domain management platform, the platform including a client and a server, wherein the client is deployed on a target terminal, the method includes: The client sends a domain joining request to the server. The server responds to the domain join request and obtains the administrator login information from the domain join request; The server generates domain joining credentials based on the administrator login information and sends them to the client. The client receives the domain joining certificate and encrypts it to obtain the encrypted domain joining certificate. When the client receives a login request from the target user, it performs certificate verification with the server based on the encrypted domain-adding credentials to obtain the target verification result. Based on the target verification result, the target user is authorized to log in to the target terminal; The step of generating domain joining credentials based on the administrator login information via the server and sending them to the client includes: The server performs permission verification based on the administrator login information. If the permission verification passes, the device information of the target terminal is obtained through the server. The device information includes the motherboard serial number and / or device name of the target terminal. The server, based on the device information, calls the built-in digital certificate authority to generate a domain joining certificate bound to the target terminal. The domain joining certificate includes the motherboard serial number of the target terminal and / or the device name. The server sends the domain joining certificate to the client. After authorizing the target user to log in to the target terminal based on the target verification result, the process further includes: The server generates a user certificate that is bound to the target user and the target terminal, and sends the user certificate to the client. The client receives the user certificate and encrypts it to obtain the encrypted user certificate. When the target user requests to log in to the third-party business system, based on the encrypted user certificate, the target user is provided with passwordless authentication for the third-party business system, wherein the third-party business system has been registered on the platform.

2. The terminal domain joining method based on a non-Kerberos protocol according to claim 1, characterized in that, The step of receiving the domain joining credential through the client and encrypting the domain joining credential to obtain the encrypted domain joining credential includes: The client receives the domain joining credential and obtains the local device identifier of the target terminal. The client generates encrypted parameters based on a preset fixed program key and the local device identifier. The client encrypts the domain joining credential using the encryption algorithm based on the encryption parameters to obtain the encrypted domain joining credential.

3. The terminal domain joining method based on a non-Kerberos protocol according to claim 1, characterized in that, When the client receives a login request from a target user, the client performs certificate verification with the server based on the encrypted domain-addressing credentials to obtain the target verification result, including: When the client receives a login request from the target user, it responds to the login request through the client and decrypts the encrypted domain joining credential to obtain the decrypted domain joining credential. Based on the decrypted domain encryption certificate, a two-way certificate authentication channel is established between the client and the server. The client uses the two-way certificate authentication channel to send the target user's login credentials to the server for verification and receives the target verification result from the server.

4. The terminal domain joining method based on a non-Kerberos protocol according to claim 3, characterized in that, The step of sending the target user's login credentials to the server for verification via the two-way certificate authentication channel through the client, and receiving the target verification result from the server, includes: The server verifies the user's identity based on the login credentials and generates a first verification result. The server verifies the binding relationship and validity between the domain joining credential and the target terminal based on the identification information of the decrypted domain joining credential, and obtains a second verification result. The server generates the target verification result based on the first verification result and the second verification result, and sends the target verification result to the client.

5. The terminal domain joining method based on a non-Kerberos protocol according to claim 1, characterized in that, The step of authorizing the target user to log in to the target terminal based on the target verification result includes: If the target verification result is successful, the client loads the permission policy and configuration corresponding to the target user issued by the server, and allows the target user to access the operating system of the target terminal.

6. A terminal domain joining system based on a non-Kerberos protocol, characterized in that, The system is applied to a domain management platform, which includes a client and a server. The client is deployed on a target terminal. The system executes the terminal domain joining method based on a non-Kerberos protocol as described in claim 1. The system includes: The domain join request initiation module is used to send a domain join request to the server through the client; The request processing and authentication module is used to respond to the domain joining request through the server and obtain the administrator login information in the domain joining request. The domain joining credential generation and distribution module is used to generate domain joining credentials based on the administrator login information through the server and send them to the client; The credential receiving and security processing module is used to receive the domain joining credential through the client and encrypt the domain joining credential to obtain the encrypted domain joining credential. The user login verification module is used to verify the target user's login request by having the client perform certificate verification with the server based on the encrypted domain-adding credentials, and obtain the target verification result. The login authorization module is used to authorize the target user to log in to the target terminal based on the target verification result.

7. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described in any one of claims 1 to 5, a terminal domain joining method based on a non-Kerberos protocol.

8. A computer-readable storage medium, characterized in that, The computer program is stored and can be loaded by a processor and executed as described in any one of claims 1 to 5, which is a terminal domain joining method based on a non-Kerberos protocol.

Images