Patent Description:
<CIT> discloses a secure and automated system that can be used to provision devices with configuration information.

The use of similar reference numbers in different instances in the description and the figures may indicate similar or identical items.

In various organizations, IT administrators are typically tasked with maintaining stability and security of the devices that are connected to the networks of the organization. However, over time, such devices within the organization can be increasingly exposed to security threats that may compromise data stored on the devices and the overall network, and may adversely affect functionality of the network. For instance, a device can be infected with malware that enables unauthorized access to data stored on the device, and/or that can enable functionality of the device to be hijacked by an unauthorized party. Alternatively, the device may be utilized to improperly access sensitive data stored on the network.

Upon determining that a device is compromised and can present a security risk to the organization, the device can be formatted and reset to an initial factory settings state in order to clear the compromising software that has infected the device. At this point, an IT administrator can be tasked with manually configuring the device to reestablish network connectivity in order to perform provisioning of the organization's basic settings and software on the device. In certain organizations, this configuration of the device can include reestablishing security protocols and certificates on the device, which can often be a laborious and time intensive task, as the device may be required to authenticate itself with a provisioning server, and also attest that it is clear of any malicious software or compromising data.

In certain instances, configuration techniques of the device can include the exchanging of keys between the device and a provisioning server for purposes of authenticating the device. That is, when the device is reset to an initial factory settings state, the device can automatically contact a provisioning server to request reauthorization of the device. In this instance, the device may be viewed as an unknown device to the provisioning server. As a result, the provisioning server may need to authenticate the device by way of, for example, issuing challenges by use of public or private keys to the device in order to authenticate the device for re-enrollment in the network. However, this technique of configuration presumes that the provisioning server does not know the identity of the device, and has no prior knowledge that the device may have been previously authorized to have access to the network. Moreover, such challenges are time consuming and often can require manual intervention by an IT administrator.

Certain methods can be utilized to improve upon such a key-based challenge by utilizing components that can self-authenticate the device upon resetting of the device. For example, certain devices can utilize a hardware authenticator, such as a Trusted Platform Module (TPM), to assist with various security aspects of the device, such as for authenticating a device for access to a network. A TPM can be a hardware chip, such as a microcontroller, that can be included as part of a device's motherboard. Generally, a TPM can represent a secure processing environment that can be leveraged to store security assets, such as security keys, certificates, and passwords, that can be used to authenticate a device. Further, a TPM can be utilized to store measurements of valid device states (e.g., operating system states), which can be used to ascertain whether a current device state has been compromised such that the device may be unsecure and/or untrusted.

Thus, in instances where a device may have a TPM, the device can perform a re-enrollment process for a formatted device automatically using the information associated with the TPM. That is, when a device reset command is issued to the device, the device may be restored to an initial factory settings state, and upon rebooting, may access the TPM to issue identifying information to a provisioning server for authentication and re-enrollment in the network. In such instances, while the reset device would still constitute an unknown device to the provisioning server, the reset device can identify itself and perform authentication without the need for involvement by an IT administrator.

In many instances, however, the existence of a TPM on a device can be rare, and there may be existing devices spread throughout an organization where resetting of devices may need to occur several times a day on multiple devices. As manual intervention can significantly increase the time and cost associated with resetting numerous devices, it is desirable to have a re-enrollment process for devices that lack a TPM that can be performed in an automated fashion without any user intervention.

As such, concepts disclosed herein can provide technical solutions for automatically re-enrolling devices that may lack hardware authenticators, such as a TPM, back into a network without requiring user intervention. Due to the nature of the device being a known authorized entity in the current network prior to reset, the device can be effectively preauthorized by provisioning the device with a single-use authorization, such as a one-time password (OTP), that can be stored in a persistent area of the device before the reset operation occurs, and which can be used to automatically authenticate the device and enable the device to rejoin the network upon reset.

It is to be appreciated that any reference herein to a one-time password, or OTP, is not restricted to purely passwords, and the term may include any single-use authorization method, which may include one-time pre-shared keys, single use secrets, passwords, tokens, unique identifiers, checksum values, a cryptographic nonce, or any other type of credential that can be provided for single-use authorization. Such an OTP may have restrictions associated with the OTP, such as being a time-bound credential that should be provided to an authenticating server within the time limits, or a credential that may be tied to a hardware identifier associated with the device. Thus, upon resetting of the device, the OTP can be utilized to assist with authentication and re-enrollment of the device into the network in a user-less fashion, saving the organization time and cost associated with IT administration.

With reference to <FIG>, an example system <NUM> for performing autopilot re-enrollment in accordance with techniques disclosed herein is provided. As depicted in <FIG>, system <NUM> can comprise a management server <NUM> that can be utilized to manage the formatting and provisioning of one or more managed device(s) <NUM>, which may include desktop or laptop devices <NUM>(<NUM>) or portable devices <NUM>(<NUM>), for example. The management of managed devices <NUM> may be initiated by an administrator <NUM>, who may monitor that status of managed devices <NUM> and can issue reset requests to individual devices when appropriate.

There may be multiple reasons for why a managed device may be reset, such as the device becoming compromised by malicious software, or a software update that may have rendered the device unstable during normal operation. Alternatively, as is often the case in large organizations, managed devices may frequently be reassigned between different groups within the organization or between individual employees, such as when an employee leaves the organization and the managed device remains behind in an office. In this instance, the managed device can be reset to an initial factory settings state and provisioned with software appropriate for the organization or individual.

Management server <NUM> may be in communication with managed devices <NUM> by way of a network <NUM> (e.g., the Internet or an intranet). Management server <NUM> and managed devices <NUM> may each comprise a processor <NUM> and memory <NUM>, wherein the memory <NUM> may have various software modules that can be executable by the processor <NUM> for performing the processes disclosed herein. Memory <NUM> can include both persistent storage resources, such as magnetic or solid-state drives, and volatile storage, such as one or more random-access memory devices. In some cases, the modules described herein in connection with memory <NUM> can be provided as executable instructions that are stored on persistent storage devices, loaded into the random-access memory (RAM), and read from RAM by the processor for execution.

Memory <NUM> can include or have access to a management module <NUM>, which may be a software program executable by processor <NUM> for displaying a listing of managed devices to administrator <NUM> and allowing the administrator to issue commands regarding the managed devices. For example, management module <NUM> may include a graphical user interface (GUI) that can display a visual depiction of managed devices within the organization, and present information to administrator <NUM> about the relative health or status of the managed device. Management module <NUM> may interact with a health module <NUM> that can actively monitor network and remote device health across the network in real-time. Alternatively, health module <NUM> may utilize a database <NUM> to determine whether IT service tickets have been issued regarding any managed devices.

For example, a managed device on the network may have been detected by health module <NUM> as making malicious attempts to access certain secured portions of the organizations network. Management module <NUM> may therefore display a visual indicator that can depict to administrator <NUM> that the managed device may be compromised, and can further recommend that the managed device be reset to an initial factory settings state. Alternatively, a user of a managed device may have submitted an IT service ticket through an online portal, indicating that the managed device is exhibiting problematic behavior. Management module <NUM> can therefore display a visual indication to administrator <NUM> that a service ticket has been issued for the particular managed device, and administrator <NUM> can instruct management server <NUM> to issue a reset command to the managed device in order to fix the problematic behavior.

Administrator <NUM> may select a particular managed device by way of the GUI, such as by way of a cursor or by interacting with a touch-sensitive display associated with management server <NUM>, in order to review detailed information regarding the managed device, such as information collected by health module <NUM>. Administrator <NUM> can then issue commands regarding the managed device, such as a reset command to have management module <NUM> handle resetting of the managed device. In certain implementations, management module <NUM> can allow administrator <NUM> to select a plurality or all of the managed devices, which may allow management server <NUM> to perform batch operations on multiple managed devices. Such reset commands may be issued by administrator <NUM> depending on a number of different factors.

Alternatively, in some implementations, management module <NUM> may be configured to automatically determine that certain managed devices should be issued a reset command immediately, without waiting for approval or interaction by administrator <NUM>. For example, administrator <NUM> may configure management module <NUM> to automatically issue a reset command to a managed device if certain criteria regarding the observed health of the managed device becomes known, such as if the managed device contains a malicious threat. In certain implementations, health module <NUM> may consult a listing that may be stored in database <NUM>, detailing known dangerous malicious viruses or software. Then, if health module <NUM> determines that a managed device includes any such virus or software, an immediate reset command can be sent to the managed device to prevent further spread throughout the network.

In certain implementations, administrator <NUM> may interact directly with management server <NUM>, and may issue reset requests directly to management server <NUM> such as described above via management module <NUM>. Alternatively, administrator <NUM> may utilize a remote device <NUM> that may have network monitoring capabilities. For example, remote device <NUM> may interact with management server <NUM>, and more specifically, can interact with management module <NUM> and health module <NUM> to provide detailed information to administrator <NUM> at a remote setting. Administrator <NUM> can therefore issue commands to management module <NUM> remotely by way of remote device <NUM>.

Remote device <NUM> may be a standard computing device, such as a desktop or laptop computer, or may be a portable computing device, such as a mobile phone. Alternatively, remote device <NUM> may be an interactive device that can be voice controlled by administrator <NUM>. For example, remote device <NUM> may be an interactive device that enables human interaction with management server <NUM> via, for example, voice commands. Such remote devices may include, for example, various "smart" home electronics devices or "Internet of things" (IoT) devices that may be communicatively coupled to network(s) <NUM> for interaction with management server <NUM>.

Upon issuance of a reset command to managed device <NUM>, management server <NUM> coordinates the issuance of an OTP to the remote device for use by the device in autopilot re-enrollment, i.e., an automated authorization and re-enrollment into the network. The OTP is stored in a persistent storage area <NUM> associated with managed device <NUM>, where the OTP can persist even after resetting of the device to an initial factory settings state. Persistent storage area <NUM> may also store an image of the initial factory settings state, for loading into memory upon erasing of the memory of the device.

Resetting of managed device <NUM> can be performed in accordance with a reset module <NUM>, which may be a firmware-based program that can erase data associated with managed device <NUM>, and load new data to the device according to the image stored in persistent storage area <NUM>. Then, once the device is restored to the initial factory settings state, the OTP can be extracted and used by the device in an automatic authentication and re-enrollment process. Upon issuance of the OTP to managed device <NUM>, management server <NUM> may store a copy of the OTP on an OTP storage server <NUM>, which can be used as a repository of current and previously used OTPs. Specifics of the autopilot re-enrollment process is described below with reference to <FIG>.

<FIG> depicts an example process <NUM> for autopilot re-enrollment which may be performed by system <NUM>, in accordance with one implementation. As depicted in <FIG>, administrator <NUM> may issue a reset device command at step <NUM> to management server <NUM>. As discussed earlier, administrator <NUM> may utilize a graphical user interface on management server <NUM> to select one or more managed devices from a listing of known managed devices, and upon selection of one or more of the managed devices, instruct a resetting operation for the managed devices, thereby initiating a reset device command. Alternatively, administrator may utilize remote device <NUM> to interact with management server <NUM> in order to initiate reset device command.

Upon receipt of a reset device command, management server <NUM> may initiate a management session of managed device <NUM> at step <NUM>. This may place a lock on the managed device <NUM> to prevent a user from inadvertently using the managed device while it is being reset. Next, at step <NUM>, management server <NUM> may query the device capabilities of managed device <NUM>, such as to determine the existence of a hardware authenticator. As noted earlier, certain managed devices may include a TPM, and if a TPM is included with the managed device, the TPM can be used to perform automatic re-enrollment for the device. However, in the instance that the TPM is either missing or disabled, managed device <NUM> can indicate this condition to management server <NUM> at step <NUM>. Having received a message specifying the capabilities of the managed device, management server <NUM> can send a synchronizing message to managed device <NUM> at step <NUM> to ensure that both systems are synced.

Next, at step <NUM>, management server <NUM> may generate the OTP to be used for autopilot re-enrollment of managed device <NUM>. The OTP can be a password that may expire after a single use, and may have one or more validity criterium that are to be met for management server <NUM> to accept the OTP when it is supplied by managed device <NUM>. For example, the OTP may be associated with a time-bound validity, where the OTP may be valid only if it is provided to management server <NUM> within the time limits imposed by the time-bound validity. Alternatively, the OTP can have a credential that may be tied to a hardware identifier associated with the device, such that an OTP that does not match with particular expected hardware of a managed device may not be accepted. As another example, the OTP can be location-bound, such that the OTP must be received by a device within a certain IP address range or geographical area defined by a network.

The OTP may be generated as a collection of data that may include the validity criteria, and may be stored in an OTP "blob," a term referring to a collection of data. Additionally, the OTP blob may contain data, such as an automated script that can execute after the resetting operation, that can enable managed device <NUM> to reestablish contact with management server <NUM> after the resetting operation is complete, in order to provide the OTP blob back to the management server. Alternatively, instead of contacting management server <NUM>, managed device <NUM> may access particular configuration data that may also be stored within the OTP blob, such as a particular wireless name and/or password, or alternatively a security certificate for local network connections.

In some implementations, the blob may store the data as a number of name/value pairs, and the automated script can look for an explicit policy stored within the name/values pairs. For example, the script may attempt to locate an explicit policy name in the name/values pairs having a name specifying that the value is the OTP, such as by searching for a "OnetimePasswordData" name, and extracting the associated value. The OTP blob can also contain additional data, such as one or more of an issue date, an expiration time, an expiration time hint (such as to specify when the validity of the OTP may expire), a nonce that can be used for validation, and/or a signed hash value, such as one generated via SHA-<NUM>) to confirm that the OTP blob has not been modified after management server <NUM> generated the blob.

At step <NUM>, management server <NUM> may store the generated OTP blob on OTP storage server <NUM>, which may include a database for storing a plurality of OTP blobs and handling requests received from management server <NUM> to store and retrieve blobs. At step <NUM>, management server <NUM> may also send the generated OTP blob to managed device <NUM> for installation into persistent storage area <NUM>, which may be a non-volatile storage area. Upon installation of the blob, an acknowledgment at step <NUM> can be provided back to management server <NUM>, confirming that the OTP blob was installed into the persistent memory of managed device <NUM>.

Upon receiving the acknowledgment that the OTP blob was successfully installed, management server <NUM> can issue a reset device command at step <NUM> to have managed device <NUM> do a reset. At step <NUM>, reset module <NUM> may automatically initiate a resetting operation of managed device <NUM> to restore the device to an initial factory settings state, such as by using an image stored in persistent storage area <NUM>. The managed device <NUM> may have the data stored in its memory erased, thereby getting rid of any potential malicious software or software issues that may be causing the device to malfunction.

Once the resetting operation is completed, at step <NUM>, managed device <NUM> may automatically reestablish communication with management server <NUM>, such as by executing an automated script that may be contained in the OTP blob, and can provide a post-reset password in the form of the OTP that was stored in persistent storage area <NUM> to management server <NUM> for authentication. At step <NUM>, having received the OTP issued by managed device <NUM>, management server <NUM> may contact OTP storage server <NUM> to retrieve the OTP blob that was previously stored on the server at step <NUM>. The OTP blobs stored on OTP storage server <NUM> may be indexed according to identifiers associated with the managed devices, such that management server <NUM> can provide the managed device identifier to OTP storage server <NUM> for easy retrieval of the correct OTP blob.

Upon receiving the OTP blob from OTP storage server <NUM>, management server <NUM> can validate the OTP that was received from managed device <NUM> at step <NUM>. Specifically, management server <NUM> can compare the OTP received from the managed device to the OTP that was retrieved from OTP storage server <NUM>, and confirm that the password match. Furthermore, management server <NUM> can additionally confirm that any validity criteria associated with the OTP are met.

For example, management server <NUM> may confirm that the OTP received from managed device <NUM> was received within the time period specified by a time-bound validity criteria associated with the received OTP. Alternatively, management server <NUM> may confirm that the OTP is received from a device within an expected IP address range, an expected geographical location, and/or other such parameters. If management server <NUM> determines that the OTP received from managed device <NUM> is invalid, management server <NUM> can reject the OTP authentication request, and indicate to an administrator that the particular managed device may require manual intervention.

Upon validation of the OTP, at step <NUM>, management server <NUM> may send an acknowledgment of validation of the OTP to managed device <NUM>, which may then send a re-enrollment request at step <NUM> back to management server <NUM>. The re-enrollment request can request that managed device <NUM> be provided with the previously granted security settings and/or certificates that were associated with the managed device prior to the resetting operation. At step <NUM>, management server <NUM> can re-enroll the newly reset managed device into the organization's network and provide the various security settings and/or certifications that were associated with the managed device to allow it to communicate on the network.

Finally, at step <NUM>, OTP storage server may periodically perform a cleanup of OTP blobs that are stored within the database. For example, OTP storage server may determine that all OTP blobs that have been expired for <NUM> days can be expunged, and notification of such expunged OTP blobs can be reported back to management server <NUM>, so that management server <NUM> can invalidate the issued OTPs.

It is to be appreciated that alternative or additional steps may be provided beyond those specified in <FIG>. For example, if a managed device is determined to have malicious software installed on the device prior to device reset, an additional holding step may be provided in the autopilot re-enrollment process. In this situation, the device may go through the reset process and provide the OTP back to management server <NUM>, and upon validating the OTP received from managed device <NUM> at step <NUM>, management server <NUM> may issue a notification to administrator <NUM> providing a detailed report on why the managed device was reset, and allowing selection of a confirmation from the administrator as to whether management server <NUM> should continue with the re-enrollment process. This can provide administrator <NUM> with additional time to do a personal check of the computer system or the user associated with the computer system, in order to avoid any repeated risk violations in the future.

Thus, as the steps of process <NUM> can be fully automated with the exception of issuing the initial reset command from the administrator, the organization can save an incredible amount of time and workforce cost in performing organization-wide resetting of managed devices.

The following discussion presents an overview of functionality that can provide autopilot re-enrollment functionality as described above. <FIG> illustrates an example method <NUM>, consistent with the present concepts. Method <NUM> can be implemented by a single device, e.g., management server <NUM>, or can be distributed over one or more servers, client devices, etc. Moreover, method <NUM> can be performed by one or more modules, such as management module <NUM> and/or health module <NUM>.

At block <NUM>, a request may be received to reset a managed device. For example, an administrator <NUM> may issue a request for managed device <NUM> to have a reset operation performed by management module <NUM>. Administrator <NUM> may issue a direct request to have managed device <NUM> reset, or in some implementations, health module <NUM> may automatically initiate the request based on a monitored state of managed device <NUM>. For example, if health module <NUM> determines that managed device <NUM> contains a malicious threat, a reset request may be issued without need for administrator involvement.

At block <NUM>, management module <NUM> can determine whether managed device <NUM> lacks a hardware authenticator, such as a TPM, which would enable the device to automatically validate itself to the network. As it can be determined that managed device <NUM> does not include a hardware authenticator, at block <NUM>, management module <NUM> can generate a one-time password to be used by the managed device for validation and re-enrollment of the managed device in the network after a reset.

At block <NUM>, the one-time password can be issued to managed device <NUM>, and this one-time password can be stored in persistent storage area <NUM> of the managed device. Then, at block <NUM>, management module <NUM> can issue a reset command to managed device <NUM>, which can cause the managed device to perform reset activities and revert to an initial factory settings state.

At block <NUM>, management module <NUM> can receive a one-time password back from managed device <NUM> following the reset operation of the managed device. Then, at block <NUM>, management module <NUM> can validate the one-time password, such as by comparing the received one-time password to the one-time password that was previously issued to the managed device. Furthermore, management module <NUM> may validate whether certain validation criteria associated with the one-time password are met, such as whether the one-time password was received within a time limit imposed by a time-bound or location-bound validity criteria.

Finally, at block <NUM>, upon validation of the one-time password received by managed device <NUM>, management module <NUM> may issue network settings to the managed device for re-enrollment of the managed device onto the network. In some implementations, such issued network settings may also include certain provisioning settings and/or software that should be associated with the managed device.

As noted above with respect to <FIG>, system <NUM> may include several devices, including a management server <NUM>, managed devices <NUM>, remote device <NUM>, and OTP storage server <NUM>. As also noted, not all device implementations can be illustrated, and other device implementations should be apparent to the skilled artisan from the description above and below.

The term "device", "computer," "computing device," "client device," "server," and or "server device" as possibly used herein can mean any type of device that has some amount of hardware processing capability and/or hardware storage/memory capability. Processing capability can be provided by one or more hardware processors (e.g., hardware processing units/cores) that can execute computer-readable instructions to provide functionality. Computer-readable instructions and/or data can be stored on persistent storage or volatile memory. The term "system" as used herein can refer to a single device, multiple devices, etc..

Memory <NUM> can be storage resources that are internal or external to any respective devices with which it is associated. Memory <NUM> can include any one or more of volatile or non-volatile memory, hard drives, flash storage devices, and/or optical storage devices (e.g., CDs, DVDs, etc.), among others. As used herein, the term "computer-readable media" can include signals. In contrast, the term "computer-readable storage media" excludes signals. Computer-readable storage media includes "computer-readable storage devices. " Examples of computer-readable storage devices include volatile storage media, such as RAM, and non-volatile storage media, such as hard drives, optical discs, and flash memory, among others, which may constitute memory <NUM>.

In some cases, the devices are configured with a general-purpose hardware processor and storage resources. In other cases, a device can include a system on a chip (SOC) type design. In SOC design implementations, functionality provided by the device can be integrated on a single SOC or multiple coupled SOCs. One or more associated processors can be configured to coordinate with shared resources, such as memory, storage, etc., and/or one or more dedicated resources, such as hardware blocks configured to perform certain specific functionality. Thus, the term "processor," "hardware processor" or "hardware processing unit" as used herein can also refer to central processing units (CPUs), graphical processing units (GPUs), controllers, microcontrollers, processor cores, or other types of processing devices suitable for implementation both in conventional computing architectures as well as SOC designs.

For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-α-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc..

In some configurations, any of the modules/code discussed herein can be implemented in software, hardware, and/or firmware. In any case, the modules/code can be provided during manufacture of the device or by an intermediary that prepares the device for sale to the end user. In other instances, the end user may install these modules/code later, such as by downloading executable code and installing the executable code on the corresponding device.

Also note that devices generally can have input and/or output functionality. For example, computing devices can have various input mechanisms such as keyboards, mice, touchpads, voice recognition, gesture recognition (e.g., using depth cameras such as stereoscopic or time-of-flight camera systems, infrared camera systems, RGB camera systems or using accelerometers/gyroscopes, facial recognition, etc.). Devices can also have various output mechanisms such as printers, monitors, etc..

Also note that the devices described herein can function in a stand-alone or cooperative manner to implement the described techniques. For example, the methods described herein can be performed on a single computing device and/or distributed across multiple computing devices, such as IoT devices, that communicate over one or more network(s). Without limitation, such one or more network(s) can include one or more local area networks (LANs), wide area networks (WANs), the Internet, and the like.

Various device examples are described above. Additional examples are described below. One example includes a system comprising a processor and a computer-readable storage media storing instructions that, when executed by the processor, cause the system to automatically manage a reset operation for a managed device by: generating a one-time password for use by the managed device in re-enrollment of the managed device in a network following the reset operation, issuing the one-time password to the managed device, receiving an authentication request from the managed device following the reset operation, the authentication request including a post-reset password, and validating the post-reset password against the issued one-time password to confirm re-enrollment of the managed device in the network.

Another example can include any of the above and/or below examples where automatically managing the reset operation of the managed device further comprises displaying a listing of managed devices on a graphical user interface, receiving a selection of the managed device from the listing of managed devices to indicate that a reset operation should be performed on the selected managed device, and issuing a reset operation to the selected managed device.

Another example can include any of the above and/or below examples where validating the post-reset password comprises checking the post-reset password against a one-time password stored on a storage server.

Another example can include any of the above and/or below examples where validating the post-reset password further comprises checking the post-reset password against a validity criteria.

Another example can include any of the above and/or below examples where the validity criteria is a time-bound validity criteria, and the post-reset password must be received from the managed device within a time limit specified by the time-bound validity criteria.

Another example can include any of the above and/or below examples where the validity criteria is a location-bound validity criteria.

Another example can include any of the above and/or below examples where automatically managing the reset operation of the managed device further comprises determining whether the managed device includes a hardware authenticator for re-enrollment of the managed device on the network after reset of the managed device.

Another example can include any of the above and/or below examples where the reset operation is submitted by an administrator of the network.

Another example can include any of the above and/or below examples where the reset operation is automatically initiated by the system upon determining that the managed device contains a malicious threat.

Another example can include any of the above and/or below examples where issuing the one-time password to the managed device further comprises instructing the managed device to install the one-time password in a persistent storage area such that the one-time password persists through the reset operation.

Another example can include any of the above and/or below examples where automatically managing the reset operation of the managed device further comprises issuing to the managed device, after the post-reset password is validated, network settings that were associated with the managed device prior to the reset operation.

Another example includes a method comprising receiving a request to reset a device on a network, determining that the device does not include a hardware authenticator for re-enrollment of the device on the network after reset of the device, generating a one-time password for use by the device in automatic re-enrollment in the network after reset of the device upon determining that the device does not include the hardware authenticator, and issuing the generated one-time password to the device.

Another example can include any of the above and/or below examples where the method further comprises receiving the one-time password from the device after the device was reset, validating the one-time password, and automatically providing network settings to the device that were present on the device prior to reset of the device.

Another example can include any of the above and/or below examples where validating the one-time password comprises checking the one-time password against a one-time password stored on a storage server.

Another example can include any of the above and/or below examples where validating the one-time password further comprises checking the one-time password against a validity criteria.

Another example can include any of the above and/or below examples where the validity criteria is a time-bound validity criteria, and the one-time password must be received from the device within a time limit specified by the time-bound validity criteria.

Another example includes a system comprising a processor and a memory storing computer-readable instructions, which when executed by the processor, cause the processor to re-enroll the system in a network automatically by: receiving, from a management server, a one-time password for use in re-enrollment of the system into a network, installing the one-time password into a persistent storage area, initiating a reset process to reset the system to an initial factory settings state, and issuing the one-time password that was installed in the persistent storage area to the management server for validation to re-enroll the system in the network.

Another example can include any of the above and/or below examples where the system further comprises receiving, from the management server, network settings that were associated with the system prior to initiating the reset process.

Another example can include any of the above and/or below examples where the one-time password stored in the persistent storage area persists through the reset process.

Another example can include any of the above and/or below examples where the system further comprises indicating, to the management server, that a hardware authenticator is not present in the system.

Claim 1:
A system (<NUM>) comprising:
a processor (<NUM>); and
a computer-readable storage media (<NUM>) storing instructions that, when executed by the processor (<NUM>), cause the system (<NUM>) to automatically manage a reset operation for a managed device (<NUM>) by:
determining that the managed device (<NUM>) does not include a hardware authenticator for re-enrollment of the managed device (<NUM>) on a network after reset of the managed device (<NUM>);
upon determining that the managed device (<NUM>) does not include the hardware authenticator, generating a one-time password for use by the managed device (<NUM>) in re-enrollment of the managed device (<NUM>) in the network following the reset operation;
issuing the one-time password to the managed device (<NUM>), wherein issuing the one-time password to the managed device (<NUM>) further comprises instructing the managed device (<NUM>) to install the one-time password in a persistent storage area (<NUM>) such that the one-time password persists through the reset operation;
receiving an authentication request from the managed device (<NUM>) following the reset operation, the authentication request including a post-reset password; and
validating the post-reset password against the issued one-time password to confirm re-enrollment of the managed device (<NUM>) in the network.