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

Re: [HTCondor-users] restricting admin commands



So My thought is that unless I have a Kerberos user named "root", Kerberos won't work since root is only a local user. However, happy to see where this takes us if you think it could help you.

 I set my id as part of the administrator list (ALLOW_ADMINISTRATOR = condor@*, root@*, gpezza2@*)

When logged in as root:
klist gives me: 
klist: No credentials cache found (filename: /tmp/krb5cc_0)

condor_ping gives me: 
[root@slot3 ~]# condor_ping -verbose ADMINISTRATOR
ADMINISTRATOR failed!
AUTHENTICATE:1003:Failed to authenticate with any method
AUTHENTICATE:1004:Failed to authenticate using KERBEROS

if I login as myself (and kinit), I get: 
[gpezza2@slot3 root]$ klist
Ticket cache: FILE:/tmp/krb5cc_291948
Default principal: gpezza2@xxxxxxxxxxxxxxxx

Valid starting       Expires              Service principal
06/03/2020 18:59:13  06/04/2020 04:59:13  krbtgt/AD.UILLINOIS.EDU@xxxxxxxxxxxxxxxx
        renew until 06/10/2020 18:59:08

condor_ping gives me the same info:
[gpezza2@slot3 root]$ condor_ping -verbose ADMINISTRATOR
ADMINISTRATOR failed!
AUTHENTICATE:1003:Failed to authenticate with any method
AUTHENTICATE:1004:Failed to authenticate using KERBEROS

If I switch to KERBEROS, FS, everything now "works", bit looking at condor_ping tells me everything is authenticating through FS, and I still get the same AUTHENTICATE:1004 error regarding Kerberos. So there is something missing there. My domain on condor is set to "illinois.edu" so I tried adding a Kerberos map file with this in it:

AD.UILLINOIS.EDU = illinois.edu
Same results, I tried specifying the server principle to the same thing klist gives me, with no change, I tried changing my UID to match my realm, and still no luck.

Reason I started going after the server principle was one of the errors was saying it could not communicate with the principle. Now that I overwrote that, the error I get in the SchedLog is: Kerberos server authentication error:Service key not available
 
-------------------------------------
Gianni Pezzarossi
Computational System Analyst
User Services:Research
Engineering IT Shared Services
University of Illinois @ Urbana-Champaign


-----Original Message-----
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of Zach Miller
Sent: Wednesday, June 3, 2020 2:21 PM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: Re: [HTCondor-users] restricting admin commands

Hello,

Glad you got it working with FS.  I am curious about the Kerberos (AD) setup though because if HTCondor is doing the wrong thing or has bad default behavior I would like to know for future use.  When you are logged in as the root and/or condor user locally, what do you see if you run "klist"?  What about "klist -k"?  Possibly HTCondor could authenticate as one of these principals to do administrative commands.  (The advantage to that would be you could do them remotely if you ever needed to.)

Thanks!


Cheers,
-zach


ïOn 6/3/20, 2:13 PM, "HTCondor-users on behalf of Pezzarossi, Gianni" <htcondor-users-bounces@xxxxxxxxxxx on behalf of gpezza2@xxxxxxxxxxxx> wrote:

    Awesome! Thanks Zach, I got the FS one to work for me, which I'll say is good enough for now since I only care to auth local users.

    I could not get Kerberos to work though, but I think that one made sense, since the user "root" does not exist in our Kerberos (shared Active Directory). Same for the "condor" user, so that actually seems to work as expected since I can't kinit as either of those users. So I guess that was silly to ask initially :-p

    Anyway, thanks again!

    -------------------------------------
    Gianni Pezzarossi
    Computational System Analyst
    User Services:Research
    Engineering IT Shared Services
    University of Illinois @ Urbana-Champaign
    (217)244-7549
    2312 Siebel Center for Computer Science
    engrit-help@xxxxxxxxxxxx

    -----Original Message-----
    From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of Zach Miller
    Sent: Tuesday, May 26, 2020 4:25 PM
    To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
    Subject: Re: [HTCondor-users] restricting admin commands

    Hello,

    There are many ways to do this, but If you already have a Kerberos infrastructure set up, that should be fairly easy to use, in theory at least.

    First, add these lines to the condor_config:
    	SEC_ADMINISTRATOR_AUTHENTICATION_METHODS = KERBEROS
    	SEC_ADMINISTRATOR_AUTHENTICATION = REQUIRED
    	SEC_ADMINISTRATOR_INTEGRITY = REQUIRED
    	ALLOW_ADMINISTRATOR = condor@*, root@*

    You'll need to reconfig your daemons to have that take effect. (** Note that if the new settings don't work, you won't be able to run reconfig anymore since that itself is an ADMINISTRATOR command!  You can always use "service condor stop/start" as root if needed).

    The above forces HTCondor to authenticate administrator commands and then only allow them from root or the condor user.  Just FYI, the default "host/blah.cs.wisc.edu" Kerberos principal will by default map to "condor" and not "root".

    You can also use FS (File System) authentication, which only works locally (because it uses the /tmp directory).  This is more lightweight and doesn't use any network traffic or KDC resources.  To use that, change the first line to:
    	SEC_ADMINISTRATOR_AUTHENTICATION_METHODS = FS

    Finally, you can tell condor to try FS first, and if that fails (perhaps because you are doing a condor_off to a remote machine) then try Kerberos:
    	SEC_ADMINISTRATOR_AUTHENTICATION_METHODS = FS, KERBEROS


    After making the config changes (and doing the reconfig), test it out by running this as root:
    	condor_ping ADMINISTRATOR

    You should hopefully see a line similar to this:
    	ADMINISTRATOR using (no encryption, MD5, and KERBEROS) succeeded as condor@xxxxxxxxxxx

    Then also check that same command as a regular user and you should get something like this:
    	ADMINISTRATOR failed!  Use -verbose for more information.

    This is all assuming of course that Kerberos authentication with HTCondor is working.  If not, we can debug that, or set things up to use a different authentication method.

    As you mentioned, host-based authorization is not very good and would allow bad users to manipulate the system.  You should also enable security for DAEMON level authorizations.  Assuming you have some authentication method working that is as easy as just doing this:
    	SEC_DAEMON_AUTHENTICATION_METHODS = KERBEROS
    	SEC_DAEMON_AUTHENTICATION = REQUIRED
    	SEC_DAEMON_INTEGRITY = REQUIRED
    	ALLOW_DAEMON = condor@*, root@*

    If you need any help getting authentication working, please let me know.  (If it's a more involved or you need to include private information you can submit a ticket to htcondor-admin@xxxxxxxxxxx while we work through the details off-list, and then I post a summary of the results back here for reference.  That's up to you though.)


    Cheers,
    -zach



    On 5/22/20, 3:53 PM, "HTCondor-users on behalf of Pezzarossi, Gianni" <htcondor-users-bounces@xxxxxxxxxxx on behalf of gpezza2@xxxxxxxxxxxx> wrote:

        Greetings,
        I have a condor cluster where one system is both the submission machine and central manager and it just struck me that because of default host-based auth, it means all users on the system can use admin-level condor commands (such as condor_userprio).
         I am going to see about moving submission to its own system since that simplifies the auth piece, however I wonder if there is another easy way to restrict it so that only root can use admin commands, and all the other users cannot. I tried looking into setting
         up one of the authn /authz setups like Kerberos since that is what we use for system login, but I cannot get it to work, plus I donât think it would work with the local root account anyway. Any suggestions as to what I can use to restrict admin commands to
         just root?

        Thanks. (running version 8.8 btw)

        -------------------------------------
        Gianni Pezzarossi
        Computational System Analyst
        User Services:Research
        Engineering IT Shared Services
        University of Illinois @ Urbana-Champaign




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