none
Can we turn off windown authentication in window 2008 hpc when running a client application to connect a headnode?

    Question

  • Hi,

    It seems a windown authentication is always required in window 2008 hpc when running a client application to connect a headnode, please see message below. is there any way we can turn off windows authentication or use some security credential without this popup message?

    >>Enter the password for 'Domain\useraccount1' to connect to 'headnode':

    I tried to add an network account from control panel - manager network user passwords but it still has this message with my window loginID? Any suggestion is highly appreicated!

    • Moved by Alex SuttonOwner Tuesday, October 27, 2009 11:20 AM (From:Windows HPC Server Developers - General)
    Monday, September 7, 2009 2:30 PM

Answers

  • When you submit a job, two authentications occur. The first occurs when you run, say, the job.exe command under the authority of a domain user, and job.exe tries to create an authenticated .Net remoting connection to a service running on the cluster headnode. This requires a Windows (Kerberos) authentication. The second authentication occurs when the scheduler needs to start the job running on a compute node and needs user credentials for starting the corresponding process. These credentials can be supplied either on the job.exe command line or by entering them once and caching them on the client so they don't have to be entered next time.

    We need to be clear whether you're asking about the first case or the second. If it is the first case, then you need to make sure that you are launching the job.exe command under the authority of a domain account that the cluster admin has previously added as a cluster user. Windows should not be asking for a password in this case unless you are using, say, the Runas command or some other means of launching job.exe. Also, you should not be running job.exe under the authority of a local user.

    For the second case, you should just need to enter the domain user name/password once at the prompt and it will be cached or, as Don said, by running "cluscfg setcreds" beforehand.

    Keep in mind also that the two authentications can be for completely different domain users. For example, consider the case where the job is submitted by user A, but the job is to run under the authority of user B. The first authentication (.Net remoting) is for user A, and the second authentication (requiring the cached creds) is for user B.

    Friday, December 11, 2009 9:56 PM

All replies

  • You'll need to submit credentials once, but then they should remain cached for that user's workstation on that cluster.

    http://msdn.microsoft.com/en-us/library/bb525082(VS.85).aspx describes a little bit about our credential cache, and how you can submit a job that attempts to use the cached ones if available.
    Wednesday, December 9, 2009 6:58 AM
    Moderator
  • When you submit a job, two authentications occur. The first occurs when you run, say, the job.exe command under the authority of a domain user, and job.exe tries to create an authenticated .Net remoting connection to a service running on the cluster headnode. This requires a Windows (Kerberos) authentication. The second authentication occurs when the scheduler needs to start the job running on a compute node and needs user credentials for starting the corresponding process. These credentials can be supplied either on the job.exe command line or by entering them once and caching them on the client so they don't have to be entered next time.

    We need to be clear whether you're asking about the first case or the second. If it is the first case, then you need to make sure that you are launching the job.exe command under the authority of a domain account that the cluster admin has previously added as a cluster user. Windows should not be asking for a password in this case unless you are using, say, the Runas command or some other means of launching job.exe. Also, you should not be running job.exe under the authority of a local user.

    For the second case, you should just need to enter the domain user name/password once at the prompt and it will be cached or, as Don said, by running "cluscfg setcreds" beforehand.

    Keep in mind also that the two authentications can be for completely different domain users. For example, consider the case where the job is submitted by user A, but the job is to run under the authority of user B. The first authentication (.Net remoting) is for user A, and the second authentication (requiring the cached creds) is for user B.

    Friday, December 11, 2009 9:56 PM
  • Thank you for all the replies. Our case is second one. We use a domain user which is also a cluster user to run a SOA service in the cluster. We tried to cache the username/password at the prompt or "cluscfg setcreds", it works well for a small size of client machines. But the problem is we need to run it from a large size of client machines which could be 100 or more. THe other issue is what happen in case the cached username/password is cleared out unexpectly? Is it reliable in a daily high volume production environment? Right now, we use username/password each time when creating a session from client side.  
    Sunday, December 13, 2009 2:39 PM
  • Yes, you'll need to cache the credentials on each client machine by running cluscfg setcreds on each client machine. We're considering alternatives to this credential caching requirement in future versions of the product.

    Have you seen your HPC credential cache get cleared out unexpectedly?

    Sunday, December 13, 2009 8:14 PM