Re: [HTCondor-users] Client fails to extract VOMS FQAN

[Zach Miller <zmiller@xxxxxxxxxxx>]

Hello,

I think I see what is happening.  You are looking at the output from a condor_q command.  The tool is authenticating to the SchedD, which has the DN "/C=DE/O=GermanGrid/OU=KIT/CN=htcondor-ce-1-kit.gridka.de".  This looks like a host certificate, which is what I would expect the SchedD to be presenting to a tool such as condor_q.  Typically, VOMS FQAN are present in the user credentials and not the host credentials, so this looks like normal operation to me.  If you want to check that the user VOMS FQAN were read correctly by the SchedD, you would need to turn on D_SECURITY debugging for the SchedD and then look in the SchedLog to see what it did with that side of the authentication.

This made me realize I could add an enhancement to condor_ping which would echo back to you not just the resulting user you were mapped to, but also the DN (with FQAN) that the SchedD authenticated you as before the mapping.  This should be easy to add in the next dev release.

FYI, We're also on a campaign to clean up the security debugging messages... you put "D_ALL" which has quite a bit of output.  There is actually an even more verbose setting, "D_ALL:2" which can be a bit overwhelming. 


Cheers,
-zach





    Hi all,

    Iâm remote-debugging for a new group trying to use our CE. Due to the high latency of this, I was hoping someone else has seen (and solved) such a problem.

    The group is using a local HTCondor to submit to our HTCondor-CE. However, it appears their FQAN is not read properly by their local Schedd.
    Their `voms-proxy-info` shows the proper FQAN and extensions [0], but when they use any local Condor tools the FQAN cannot be read [1]:
    	ZKM: VOMS FQAN not present (error 1), ignoring.

    Are there any known reasons why HTCondor could fail to extract the VOMS FQANs? Does HTCondor require a specific certificate type, or libraries to read the VOMS FQAN?

    Cheers,
    Max

    [0] $ voms-proxy-info --fqan
    /icecube/Role=NULL/Capability=NULL

    [1] _CONDOR_TOOL_DEBUG=D_ALL condor_q -name htcondor-ce-1-kit.gridka.de -pool htcondor-ce-1-kit.gridka.de:9619 -debug
    09/08/20 09:13:18 (fd:4) (pid:54888) (D_SECURITY) SECMAN: new session, doing initial authentication.
    09/08/20 09:13:18 (fd:4) (pid:54888) (D_SECURITY) SECMAN: Auth methods: GSI
    09/08/20 09:13:18 (fd:4) (pid:54888) (D_SECURITY) AUTHENTICATE: setting timeout for <192.108.45.11:9619?addrs=192.108.45.11-9619+[2a00-139c-3-2e5-0-61-1-6a]-9619&alias=htcondor-ce-1-kit.gridka.de&noUDP&sock=2207_1748_3> to 20.
    09/08/20 09:13:18 (fd:4) (pid:54888) (D_SECURITY) HANDSHAKE: in handshake(my_methods = 'GSI')
    09/08/20 09:13:18 (fd:4) (pid:54888) (D_SECURITY) HANDSHAKE: handshake() - i am the client
    09/08/20 09:13:18 (fd:6) (pid:54888) (D_SECURITY) HANDSHAKE: sending (methods == 32) to server
    09/08/20 09:13:18 (fd:6) (pid:54888) (D_SECURITY) HANDSHAKE: server replied (method = 32)
    09/08/20 09:13:18 (fd:7) (pid:54888) (D_SECURITY) ZKM: VOMS FQAN not present (error 1), ignoring.
    09/08/20 09:13:18 (fd:7) (pid:54888) (D_SECURITY) IPVERIFY: for htcondor-ce-1-kit.gridka.de matched 192.108.45.11 to 192.108.45.11
    09/08/20 09:13:18 (fd:7) (pid:54888) (D_SECURITY) valid GSS connection established to /C=DE/O=GermanGrid/OU=KIT/CN=htcondor-ce-1-kit.gridka.de
    09/08/20 09:13:18 (fd:7) (pid:54888) (D_SECURITY) Authentication was a Success.