Intel® MPI Library
Get help with building, analyzing, optimizing, and scaling high-performance computing (HPC) applications.
2154 Discussions

Intel MPI on Windows Authorization questions

jackyjngwn
Beginner
2,279 Views
Hi,

I am running Intel MPI on my laptop with Windows Vista. I am now a little confused regarding the authorization process, and hope someone could help me with it.

First, I am able to avoid giving credentials each time I run a MPI program by registering myself using wmpiregister. However, it seemed that I could achieve the same thing by setting I_MPI_AUTH_METHOD=delegate. How does this variable work and is it secure?

Also, it seemed that if I use -localroot, I will not be asked for password either even if I_MPI_AUTH_METHOD=password. Why does this happen? Is it because that by using -localroot, I am able to bypass the SPMD daemon?

Thanks.
0 Kudos
11 Replies
James_T_Intel
Moderator
2,279 Views
Hi,

In Windows*, there are threeauthentication methods used. The default is to simplyprovide a username and password. Using wmpiregister stores a username and password in the registry (encrypted). These will be used to authenticate to the target computer. If you change your system password, you will need to rerun wmpiregister with the new password.

Using I_MPI_AUTH_METHOD=delegate (or mpiexec -delegate) causes mpiexec to use yourdomain login credentials to authenticate to the target computer. If you change your password, you will not need to change anything for mpiexec, as it will automatically pass the new authentication.

A third method is I_MPI_AUTH_METHOD=impersonate (or mpiexec -impersonate). This will use a limited domain-based authentication. This does not allow file access to network drives (even if mapped locally), and should only be used when other options will not work.

Yes, -localroot bypasses SMPD and launches local processes directly from mpiexec. This will avoid the need for authentication on the local machine, but remote machines will still need authentication.

I will look into the security of each method, as I do not have a good answer at this time.

Sincerely,
James Tullos
Technical Consulting Engineer
Intel Cluster Tools
0 Kudos
jackyjngwn
Beginner
2,279 Views
Hi,

In Windows*, there are threeauthentication methods used. The default is to simplyprovide a username and password. Using wmpiregister stores a username and password in the registry (encrypted). These will be used to authenticate to the target computer. If you change your system password, you will need to rerun wmpiregister with the new password.

Using I_MPI_AUTH_METHOD=delegate (or mpiexec -delegate) causes mpiexec to use yourdomain login credentials to authenticate to the target computer. If you change your password, you will not need to change anything for mpiexec, as it will automatically pass the new authentication.

A third method is I_MPI_AUTH_METHOD=impersonate (or mpiexec -impersonate). This will use a limited domain-based authentication. This does not allow file access to network drives (even if mapped locally), and should only be used when other options will not work.

Yes, -localroot bypasses SMPD and launches local processes directly from mpiexec. This will avoid the need for authentication on the local machine, but remote machines will still need authentication.

I will look into the security of each method, as I do not have a good answer at this time.

Sincerely,
James Tullos
Technical Consulting Engineer
Intel Cluster Tools

James,

Thanks for the reply. However, what I witnessed in my testing seems to be different from what you described. In particular, when I_MPI_AUTH_METHOD=password, the MPI program does not have access to mapped network drives. But when I_MPI_AUTH_METHOD=delegate or impersonate, the program is able to write to the network drive. Do you know why this happened?

Thanks,
Ling
0 Kudos
James_T_Intel
Moderator
2,279 Views
Hi Ling,

If the drive is mapped, it should be able to be accessed by I_MPI_AUTH_METHOD=password. Does the mapped drive need a different username and password than the one provided to wmpiregister? Using delegate should grant access to the drive. Using impersonate should not grant access to the mapped drive, however, I don't think it should explicitly prevent it. I'll check on that as well.

Sincerely,
James Tullos
Technical Consulting Engineer
Intel Cluster Tools
0 Kudos
jackyjngwn
Beginner
2,279 Views
Quoting jackyjngwn
James,

Thanks for the reply. However, what I witnessed in my testing seems to be different from what you described. In particular, when I_MPI_AUTH_METHOD=password, the MPI program does not have access to mapped network drives. But when I_MPI_AUTH_METHOD=delegate or impersonate, the program is able to write to the network drive. Do you know why this happened?

Thanks,
Ling


I think I found the answer to my question regarding the network drive. According to this post: http://lists.mcs.anl.gov/pipermail/mpich-discuss/2009-January/004440.html, this is due to the process manager of MPICH2. MPICH2 has a "-map" option to map a network drive temporarily, but I did not find a corresponding option in Intel MPI.

So I guess I was ableto access the network drive when I_MPI_AUTH_METHOD=delegate because in that two cases, my domain login credentials were used for the authentication for the network drives? But why could I still access the network drive when I_MPI_AUTH_METHOD=impersonate?

Thanks,
Ling

0 Kudos
jackyjngwn
Beginner
2,279 Views
Hi Ling,

If the drive is mapped, it should be able to be accessed by I_MPI_AUTH_METHOD=password. Does the mapped drive need a different username and password than the one provided to wmpiregister? Using delegate should grant access to the drive. Using impersonate should not grant access to the mapped drive, however, I don't think it should explicitly prevent it. I'll check on that as well.

Sincerely,
James Tullos
Technical Consulting Engineer
Intel Cluster Tools


James,

The mapped drives use the same username/password as the one provided to wmpiregister. I found that setting -mapall option actually solves the problem. Still, I have no idea why using impersonate allows access to the network drives.

thanks,
Ling

0 Kudos
James_T_Intel
Moderator
2,279 Views
Hi Ling,

Thereare two options for drive mapping with the Intel MPI Library for Windows*, -map and -mapall. As you have found, this will temporarily map network drives on the target computer.

Using delegate correctly allowed access to the mapped drive. However, impersonate is not intended for that. I am trying to find why it allowed you to access the mapped drive.

Sincerely,
James Tullos
Technical Consulting Engineer
Intel Cluster Tools
0 Kudos
James_T_Intel
Moderator
2,279 Views
Hi Ling,

Is your computer part of a domain? Are you running as administrator? If your user account has (Windows* domain) delegation turned on, -impersonate will behave identically to -delegate. That could be why you are able to access mapped drives using -impersonate.

Sincerely,
James Tullos
Technical Consulting Engineer
Intel Cluster Tools
0 Kudos
jackyjngwn
Beginner
2,279 Views
Hi Ling,

Is your computer part of a domain? Are you running as administrator? If your user account has (Windows* domain) delegation turned on, -impersonate will behave identically to -delegate. That could be why you are able to access mapped drives using -impersonate.

Sincerely,
James Tullos
Technical Consulting Engineer
Intel Cluster Tools


Hi James,

Yes, my computer is part of a domain. My user account is part of the local administrator group, but I am not running the program as administrator. Does this mean that my user account still have delegation turned on?

Also, could you explain to me a little more how the I_MPI_AUTH_METHOD=delegate works? What authentication process does it go through? Is it safe for me to allow someone else use that option on my machine? Thanks.

Ling

0 Kudos
James_T_Intel
Moderator
2,279 Views
Hi Ling,

Since your account is a local administrator, you are likely to have delegation turned on. This is dependent on the exact configuration of your domain (any user can have delegation turned on, administrators do by default).

Using the delgate authentication method causes MPI to use your domain authentication to authenticate when launching MPI processes. Basically, when you log in to Windows*, your login credentials are stored as long as you are logged in. Windows* can automatically pass these credentials to other computers/services for authentication. By default, MPI does not do this. Using I_MPI_AUTH_METHDO=delegate (or -delegate) causes MPI to pass the stored credentials for authentication.

If a different user logs in to the computer,MPIwill send the credentials of the user who launches the job.

MethodCredentials Used
PasswordUsername/password stored in registry or obtained at prompt
DelegateDomain login credentials stored by Windows* for current user
ImpersonateLogin credentials stored by Windows*, passed as if in a domain even if not

Hopefully that will help clear up what is happening. As to the security of each of these methods, I believe you would get a better answer from Microsoft, since Windows* handles the actual storing/passing of credentials.

Sincerely,
James Tullos
Technical Consulting Engineer
Intel Cluster Tools
0 Kudos
jackyjngwn
Beginner
2,279 Views
Thanks a lot!

Ling
0 Kudos
Christophe_H_
Beginner
2,279 Views

Hello,

I know this is an old thread but I found it very helpful. I tested it with -delegate parameter and it worked when running a simple example:

mpiexec -n 2 -delegate hostname

 

However, it does not work in the following situation:

mpiexec -n 1 -delegate master

then "master" spawns a "slave" process with "mpi_comm_spawn". The master process starts without problem but the slave always returns an error message:

abort: Unable to connect to machine.domain.com

I even tried setting the I_MPI_AUTH_METHOD=delegate environment variable and make sure it is exported by MPI using the "-genvlist I_MPI_AUTH_METHOD" command line parameter but to no avail. Is there any special to be done in such a case?

Thanks,

Chris

0 Kudos
Reply