[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] [ExternalEmail] Re: Windows credd, pool_password, run_as_owner all working, but not with Encrypt_Execute_Directory



Thanks John for the clarification of what's happening.

Yes I'm aware of this ticket. I was the one who reported the initial problem in the first place.

Just to confirm that all the nodes involved are running versions > 8.8.10

I have tried the submit file job you suggested but get the same symptoms.
That is, the job runs fine for a user that has already logged into the execute node, but gives an error
and puts the job on hold for a user that has not logged into the execute node.

Is it worth sending some log files offline?

Cheers

Greg

-----Original Message-----
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of John M Knoeller
Sent: Tuesday, 22 March 2022 5:09 AM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: Re: [HTCondor-users] [ExternalEmail] Re: Windows credd, pool_password, run_as_owner all working, but not with Encrypt_Execute_Directory

It appears that Windows manages a cache of certs on each machine that are involved in the encryption process, it will  create a certs for the user the first time the user wants to encrypt in that machine. 

So I don't think it's really a matter of checking the credentials locally as it is that the certs needed for encryption aren't available locally until that user has logged in on that machine.   The way directory encryption works on Windows changed in a Windows update and lead to a change in 8.8.10.

There is a comment in this ticket

https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=7620

That suggests a possible way to cause a cert to be created for a user by submitting a carefully crafted job.  In this case using run_as_owner rather than load_profile as the ticket suggests.

executable=c:\windows\system32\findstr.exe
arguments=cmd .job.ad
transfer_executable=false
should_transfer_files=true
output=$(cluster).out
error=$(cluster).err
run_as_owner=true
encrypt_execute_directory=true

-tj

-----Original Message-----
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of Hitchen, Greg (IM&T, Kensington WA)
Sent: Monday, March 21, 2022 3:12 AM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: Re: [HTCondor-users] [ExternalEmail] Re: Windows credd, pool_password, run_as_owner all working, but not with Encrypt_Execute_Directory

Sorry, but to make my statement a bit clearer.

It would appear that the execute node is looking for the "owner" to encrypt the execute directory
by checking local credentials on the execute node itself, whereas it is checking for the "owner" credentials
for running the job "as owner" from the credd server.

Cheers

Greg

-----Original Message-----
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of Hitchen, Greg (IM&T, Kensington WA)
Sent: Monday, 21 March 2022 3:22 PM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: Re: [HTCondor-users] [ExternalEmail] Re: Windows credd, pool_password, run_as_owner all working, but not with Encrypt_Execute_Directory

OK, I've had time to get back to this and do some more testing.

In general terms, it appears that I cannot run a job with:

run_as_owner = True
encrypt_execute_directory = True

unless I have previously logged into the execute machine itself.

Things work fine with:

run_as_owner = True
encrypt_execute_directory = False

or

run_as_owner = False
encrypt_execute_directory = True

So it would appear that the execute node is looking for the "owner" running the job
by checking local credentials on the execute node itself, rather than querying the credd server?

Is anyone able to confirm this?

I have normal and verbose log files if that helps but won't post them yet unless requested.

Thanks for any help that can be provided.

Cheers

Greg

-----Original Message-----
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of Hitchen, Greg (IM&T, Kensington WA)
Sent: Wednesday, 9 March 2022 9:39 AM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: [ExternalEmail] Re: [HTCondor-users] Windows credd, pool_password, run_as_owner all working, but not with Encrypt_Execute_Directory

Hi Todd

HTCondor Central Managers
$CondorVersion: 8.8.13 Mar 23 2021 BuildID: 534541 $
$CondorPlatform: x86_64_Ubuntu20 $

HTCondor Submit Nodes
$CondorVersion: 8.8.12 Nov 24 2020 BuildID: 524104 $
$CondorPlatform: x86_64_Windows10 $

HTCondor Execute Nodes
$CondorVersion: 8.8.12 Nov 24 2020 BuildID: 524104 $
$CondorPlatform: x86_Windows8 $

So all are > 8.8.10

Cheers

Greg

-----Original Message-----
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of Todd L Miller
Sent: Monday, 7 March 2022 11:42 PM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: Re: [HTCondor-users] Windows credd, pool_password, run_as_owner all working, but not with Encrypt_Execute_Directory

> Thanks for any info/insights/suggestions/comments.

 	HTCondor fixed a related bug in 8.8.10, so upgrade if you haven't.

- ToddM
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/

_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/

_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/

_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/

_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/