Mailing List ArchivesPublic Access |
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesPublic Access |
|
|
Glad to help. I would suspect that the *start* command doesn’t work if there is no Windows registry loaded - which would be the case if your submit file does not have run_as_owner or load_profile.
-tj From: Sam.Dana@xxxxxxxxxxx <Sam.Dana@xxxxxxxxxxx> Hello tj, Thank you for noting that condor_ping cannot test/validate PASSWORD authentication on Windows. How does one verify which "user" a job is being executed as? By changing "choice /D /Y /T %TIMETOWAIT%" to "start /wait cmd /c "choice /D Y /T %TIMETOWAIT%" I was able to get it to sleep, regardless of the "run_as_owner" setting. Now to explore running MPI jobs - any pointers? Thanks, Sam From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of John M Knoeller via HTCondor-users <htcondor-users@xxxxxxxxxxx> Hi Sam, This is going to be a bit confusing so bear with me. The confusion here is in part because what we call the PASSWORD authentication method is authenticating between daemons using a password, we call this the POOL password.
This has nothing to do with the password on any user account, it’s just a secret shared between two machines. On Linux the pool password is stored in a file that only root can read, but on Windows it is stored in a secure part of the
Windows registry that only services can read. The command condor_store_cred add -c Stores a pool password in the local registry. You must run this command on each node in the pool because the pool password cannot be stored in a CREDD, it can only be stored in the secure local
registry. Only passwords for actual users can be stored in a CREDD. And remember that the secure local registry cannot only be read by services.
Because of this condor_ping on Windows cannot be used to test PASSWORD authentication unless you run condor_ping from the LOCAL_SYSTEM account – which is not normally possible to do.
On a Linux machine, an admin can usually become root, so the tool was written assuming that an admin can impersonate a daemon. But on Windows you can’t run a tool as LOCAL_SYSTEM. (not using any command shell that you can get from Microsoft) All of this is a long winded way of explaining that you need to run condor_store_cred -c on each machine, saving the same password on each. And you can’t test PASSWORD authentication using condor_ping on Windows. If you are running HTCondor 10.0 or later, you might want to try using IDTOKEN authentication instead of PASSWORD.
-tj From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of Sam.Dana@xxxxxxxxxxx Finally, I have something a bit more concrete regarding this issue.
Running (from CM or Sched) condor_ping -type credd -verbose READ WRITE DAEMON CONFIG I get: LsaOpenPolicy returned 5 DAEMON failed! AUTHENTICATE:1003:Failed to authenticate with any method AUTHENTICATE:1004:Failed to authenticate using PASSWORD On all three systems (CM, Sched, Credd) , the logged in domain user "CVASIL\cvaadmin", has a password stored in credd condor_store_cred query Account: cvaadmin@CVASIL CredType: password A credential was stored and is valid. After ensuring the 3 systems have: condor_store_cred add -c
Account:
condor_pool@xxxxxxxxxx CredType: password Enter password: Operation succeeded. on Credd and CM, condor_store_cred query -c
Account:
condor_pool@xxxxxxxxxx CredType: password Operation failed. Make sure your ALLOW_WRITE setting includes this host. while on Sched, condor_store_cred query -c
Account:
condor_pool@xxxxxxxxxx CredType: password Operation failed because it is not allowed I had opened almost all ALLOW_ options to *, but not CREDD.ALLOW_DAEMON = condor_pool@$(UID_DOMAIN)
cvaadmin@xxxxxxxxxx I noticed the "domains" were opposite of those in store_cred, so I switched them in config Eventually, I added NTSSPI to CREDD.SEC_DAEMON_AUTHENTICATION_METHODS = PASSWORD At least condor_ping accepts it, but from what I can tell condor_submit is still not as the submit user. How do I resolve the LsaOpenPolicy issue? The logs (I read) didn't provide greater detail than the errors above. Thank you, Sam From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of
Sam.Dana@xxxxxxxxxxx <Sam.Dana@xxxxxxxxxxx> Can someone please provide "real world" config settings and steps to get Run As Owner working in a Windows 10, Windows domain environment? I can't seem to get past SEC 2007 authentication. Thanks, Sam NOTICE: This email message and all attachments transmitted with it may contain privileged and confidential information, and information that is protected by, and
proprietary to, Parsons Corporation, and is intended solely for the use of the addressee for the specific purpose set forth in this communication. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination,
distribution, copying, or other use of this message or its attachments is strictly prohibited, and you should delete this message and all copies and backups thereof. The recipient may not further distribute or use any of the information contained herein without
the express written authorization of the sender. If you have received this message in error, or if you have any questions regarding the use of the proprietary information contained therein, please contact the sender of this message immediately, and the sender
will provide you with further instructions. |