Re: [HTCondor-users] help needed to troubleshoot a "SECMAN: FAILED" issue

[Zach Miller <zmiller@xxxxxxxxxxx>]

Hi Jose,

Sorry, I meant to respond to this earlier but Mark beat me to it so I just wanted to ask a couple questions and add a couple additions to Mark's email:

It looks like you are running condor_q as root perhaps?  It (condor_q) seems to be using the pool password method of authentication and mapping you to the user "condor_pool@<domain>".  That's perhaps okay, depending on the ALLOW_* settings, but it's kind of unexpected.

You mentioned two things -- adding a SchedD to a pool, and then running condor_q.  It sounds like you got the SchedD added just fine.  Is that correct? (Is it showing up when you run condor_status -schedd?)

For the issue with condor_q you want to check the ALLOW_* settings on the SchedD machine.  Running condor_q requires READ-level authorization so you should run: "condor_config_ALLOW_READ".  For extra-nerdy goodness, use this regular expression:
	# This will show you the allow settings for all subsystems and authorization levels
	condor_config_val -dump '^(.*\.)?ALLOW'

Basically, you need an entry in the ALLOW list that authorizes the user running condor_q, whoever that may be.  You may not care and just want to set "ALLOW_READ = *".  But let us know what results you get and we'll try to help!


Cheers,
-zach

ïOn 5/28/20, 5:58 PM, "HTCondor-users on behalf of coatsworth@xxxxxxxxxxx" <htcondor-users-bounces@xxxxxxxxxxx on behalf of coatsworth@xxxxxxxxxxx> wrote:

    Hi Jose, here are a few quick troubleshooting questions.
    On your central manager machine, can you send the result of a `condor_config_val ALLOW_WRITE_COLLECTOR` command? Do you see your new schedd domain in this list?

    On both your schedd and central manager machines, can you send the result of a `condor_config_val ALLOW_DAEMON`? Again, you see your new schedd domain in both those domains.

    Can you confirm the pool password you set on the new schedd is the same as other schedds? If you're not sure, try copying the pool password file directly from another schedd that works.

    Lastly I'm pretty sure that <a_domain_name> should be your schedd domain, not the production infrastructure.

    Please give these a try and let me know, if they don't reveal the problem then I'll ask our security experts to weigh in :)

    Mark






    On Thu, May 28, 2020 at 9:29 AM <jcaballero.hep@xxxxxxxxx> wrote:


    El jue., 28 may. 2020 a las 15:17, Jose Caballero
    (<jcaballero.hep@xxxxxxxxx>) escribiÃ:
    >
    > Hi,
    >
    > I need some guidance here.
    >
    > I am trying to setup a testing Schedd and add it to an existing pool.
    > It has the same configuration that the other Schedd's on production.
    > However, there is a difference, my testing Schedd is on a host with a
    > different domain name that the rest of the infrastructure. I feel that
    > is part of the problem here.
    >
    > When I try to run condor_q remotely against the new test schedd, I get
    > this in the SchedLog
    >
    > SECMAN: FAILED: Received "DENIED" from server for user
    > condor_pool@<a_domain_name> using method PASSWORD.
    >
    > where the <a_domain_name> is the domain name of the production
    > infrastructure, not the domain name of this testing schedd.
    > Is that a problem?
    >
    > Extra info, let me know if there is something else I need to provide:
    >
    > ======================================
    > # condor_config_val SEC_PASSWORD_FILE
    > /etc/condor/pool_password
    >
    > # ls -l /etc/condor/pool_password
    > -r-------- 1 root root 256 May 28 13:22 /etc/condor/pool_password
    >
    > # rpm -qa | grep condor
    > condor-std-universe-8.6.13-1.el7.x86_64
    > condor-8.6.13-1.el7.x86_64
    > condor-procd-8.6.13-1.el7.x86_64
    > condor-externals-8.6.13-1.el7.x86_64
    > condor-external-libs-8.6.13-1.el7.x86_64
    > condor-kbdd-8.6.13-1.el7.x86_64
    > condor-cream-gahp-8.6.13-1.el7.x86_64
    > condor-python-8.6.13-1.el7.x86_64
    > condor-all-8.6.13-1.el7.x86_64
    > condor-vm-gahp-8.6.13-1.el7.x86_64
    > condor-bosco-8.6.13-1.el7.x86_64
    > condor-classads-8.6.13-1.el7.x86_64
    > ======================================
    >
    > Thanks a lot in advance.
    > Cheers,
    > Jose

    An extra piece of info.
    From the NegotiatorLog, replacing again real values by <foo>:

    ======================================
    05/28/20 15:06:39 PERMISSION DENIED to condor_pool@<a_domain_name>
    from host <the_schedd_ip> for command 421 (Reschedule), access level
    DAEMON: reason: cached result for DAEMON; see first case for the full
    reason
    05/28/20 15:06:39 DC_AUTHENTICATE: Command not authorized, done!
    ======================================

    _______________________________________________
    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/




    -- 
    Mark Coatsworth
    Systems Programmer
    Center for High Throughput Computing
    Department of Computer Sciences
    University of Wisconsin-Madison