Credential Protections in Compute Cluster Server

  • Article

Applies To: Windows Compute Cluster Server 2003

Compute cluster security is designed to give user credentials the least possible exposure as they pass from client workstation to head node to compute nodes, while maximizing usability. This includes providing encrypted storage and transport of credentials, and the use of tokens to minimize exposure of credentials on the compute nodes.

Credential processing flow

The passing of credentials from client node to head node to compute node is shown in the following diagram.

Handling of credentials

This diagram represents two distinct flows:

  • A first job submission to the cluster by a user

  • Subsequent job submissions by a user who has chosen to store his credentials on the client workstation

First submission

  1. The user submits the job from a client workstation.

  2. The user is prompted for a credential (user name and password).

  3. The user enters the credential and is given an option to store it in encrypted form in the client credential cache. This offers the convenience of not having to reenter the credential with each job submission.

  4. The credential is sent with the job along an encrypted (256-bit AES) .NET Remoting channel to the head node, where it is encrypted using DPAPI and stored with the job in the job database. If the user requested that it be stored for future use, it is returned in encrypted form to the client workstation and stored there as well, in the credential cache. It will then be automatically appended, in encrypted form, to future job submissions from that client computer.

  5. At run time, the credential is decrypted using DPAPI on the head node. The task is then dispatched with the credential to the compute node along an encrypted (256-bit AES) .NET Remoting channel.

  6. On the compute node, the credential is used to create a token and is then erased. The task is then performed under the token, which does not contain the credential.

  7. When the job is completed, the credential is erased from the job database.

Subsequent submissions

Subsequent submission is identical to first submission, except that the credential is now cached on the client and the user is not prompted for it if the user chose this option. In this case, the client will simply retrieve it from the cache and send it with the job to the head node in pre-encrypted form.

Security mechanisms

The compute cluster uses standard Windows security mechanisms. For encryption, this is standard Windows Data Protection API (DPAPI). For authentication, it is Kerberos authentication, NTLM, and the Security Support Provider Interface (SSPI). For transport, it is encrypted Component Object Model (COM) and encrypted (256-bit AES) .NET Remoting channels.