Re: [HTCondor-users] condor 8.x and authentication woes

["Bockelman, Brian" <BBockelman@xxxxxxxxxxxxx>]

Good to hear!  We have many improvements planned here; as they say, âwatch this spaceâ!

For posterity, can you share what the final problem / solution was?

Brian

Sent from my iPhone

> On Jul 3, 2019, at 5:40 AM, Keith Brown <keith6014@xxxxxxxxx> wrote:
> 
> Thanks to both of you. I have it working. Are there tests I can run to
> be comprehensive? Like submit a job, condor_status? I want to make
> sure I am using encryption.
> 
> I was beginning to abandon Condor due to complexity but its back in the hunt :-)
> 
> On Tue, Jul 2, 2019 at 9:37 AM Bockelman, Brian
> <BBockelman@xxxxxxxxxxxxx> wrote:
>> 
>> 
>> 
>>> On Jul 2, 2019, at 6:27 AM, Keith Brown <keith6014@xxxxxxxxx> wrote:
>>> 
>>> I managed to get further. The collector is able to startd from r2.
>>> 
>>> Now, when I submit my job
>>> Submitting job(s)
>>> ERROR: Failed to connect to local queue manager
>>> AUTHENTICATE:1003:Failed to authenticate with any method
>>> 
>>> I copied and pased "condor" in mapped file to "usera"
>>> 
>>> SSL /C=US/ST=MI/L=Madison/O=University of Wisconsin
>>> --Madison/O=Computer Sciences Department/OU=HTCondor
>>> Project/CN=Service condor
>>> SSL /C=US/ST=MI/L=Madison/O=University of Wisconsin
>>> --Madison/O=Computer Sciences Department/OU=HTCondor
>>> Project/CN=Service usera
>> 
>> :) ST=MI, eh?
>> 
>>> 
>>> 
>>> The schedd log looks like this
>>> Return from Handler <SecManStartCommand::WaitForSocketCallback
>>> UPDATE_SCHEDD_AD> 0.016881s
>>> 07/02/19 07:24:45 Calling Handler <DaemonCommandProtocol::WaitForSocketData> (6)
>>> 07/02/19 07:24:45 Return from Handler
>>> <DaemonCommandProtocol::WaitForSocketData> 0.000222s
>>> 07/02/19 07:24:45 Calling Handler <DaemonCommandProtocol::WaitForSocketData> (6)
>>> 07/02/19 07:24:45 DC_AUTHENTICATE: authentication of
>>> <192.168.56.101:8342> did not result in a valid mapped user name,
>>> which is required for this command (1112 QMGMT_WRITE_CMD), so
>>> aborting.
>>> 07/02/19 07:24:45 DC_AUTHENTICATE: reason for authentication failure:
>>> AUTHENTICATE:1003:Failed to authenticate with any method
>>> 07/02/19 07:24:45 Return from Handler
>>> <DaemonCommandProtocol::WaitForSocketData> 0.000109s
>>> 
>>> Any ideas?
>>> 
>> 
>> Yes - this indicates a mapping issue.  Basically, the schedd is authenticating the user as "ssl@unmapped".  Precisely, anything "@unmapped" results in this error message for submitting:
>> 
>>> 07/02/19 07:24:45 DC_AUTHENTICATE: authentication of
>>> <192.168.56.101:8342> did not result in a valid mapped user name,
>>> which is required for this command (1112 QMGMT_WRITE_CMD), so
>>> aborting.
>> 
>> 
>> This indicates the SSL authentication went OK but a valid username was not found in the mapfile.  This likely got logged a but earlier in the schedd log.
>> 
>> Brian
>> _______________________________________________
>> 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/