Re: HOSTS authentication problem

shalondwood · ‎2009-10-27

I'm trying to use host-based authentication (h

osts.equiv), but it's failing. I get the error:

"User does not have capability to invoke API quota-report."

If it's not clear, there are two spaces after 'User', as if it were printing a null username. Sure enough, from the log:

Tue Oct 27 11:44:14 CDT [near19: useradmin.unauthorized.user:warning]: User '' denied access - missing required capability: 'api-quota-report'

Am I missing something?

nagendrk · ‎2009-10-27

Try adding the user name in your code. No need to set password, just the user.

For example, in perl use the following call:

$s->set_admin_user($user, $pw);

shalondwood · ‎2009-10-27

Already trying that:

$s->set_admin_user("root", "");

Same error.

I thought perhaps it was because we do not have a user explicitly specified in our hosts.equiv file, but adding another line which explicitly specifies root doesn't change anything.

I've tried it on two filers, one running 7.2.2 and one running 7.3P6.

nagendrk · ‎2009-10-27

Try this code.. it works for me.

--

Nagendra K

shalondwood · ‎2009-10-27

Hmm.... Failed for me, but I did have to make one change, because my test filer doesn't have HTTPS set up. Does it work for you if you use HTTP transport instead of HTTPS?

nagendrk · ‎2009-10-27

Yes, it does. I just added the Server IP in /etc/hosts.equiv, then invoked this script without providing user name it worked.

Hosts.equiv file

shalondwood · ‎2009-10-27

I tried adding the ip instead of the hostname to the hosts.equiv

file, just in case that was the problem, but got the same result:

<results status="failed" reason="User does not have capability to invoke API system-get-version." errno="13003"></results>
Failed: User does not have capability to invoke API system-get-version.

Is there any sort of additional debugging I could enable?

nagendrk · ‎2009-10-27

Are logs indicating any errors?

Also, try adding " root" in /etc/hosts.equiv and invoke the script "perl hosts_ontapi_hosts.pl 10.73.69.216 root".

shalondwood · ‎2009-10-27

I see this in logs/ems:

Adding " root" to hosts.equiv didn't change anything. It looks like the problem is that it's not picking up the username for some reason. Is there some way to see if it's actually being sent?

nagendrk · ‎2009-10-27

It is quite difficult to debug this way. Try using zexplore to check things out. Meanwhile, can you send me the piece of code and the hosts.equiv file that you are using. Let me try that out and get back to you.

shalondwood · ‎2009-10-27

I discovered the problem -- the version of the SDK I had was 3.5P1, not 3.5.1. Updating solved the problem.

kcollins · ‎2009-11-04

Hi,

I am seeing the same problem as the original poster. I have SDK 3.5.1, and I can use the "remsh" command successfully from the same system where the API is failing:

cpafisc8-> sudo remsh cpafisnas1 version
NetApp Release 7.2.5.1: Wed Jun 25 08:55:16 PDT 2008

I have run the script you included (after modifying to HTTP instead of HTTPS) and I get this:

<results status="failed" reason="User does not have capability to invoke API system-get-version." errno="13003"></results>
Failed: User does not have capability to invoke API system-get-version.

I have a session logged in to the console and I see this at the time the above failure occurs:

cpafisnas1> Wed Nov 4 16:23:04 PST [cpafisnas1: useradmin.unauthorized.user:warning]: User '' denied access - missing required capability: 'api-system-get-version'

Any help would be appreciated... Do I need to have a license for "HTTP"?

Thanks,

Kevin

kcollins · ‎2009-11-05

Ok, after having found another similar thread (http://communities.netapp.com/thread/4102), I was able to resolve this problem by:

$s->set_style("LOGIN");
$s->set_admin_user("root", "");

This seems wrong to me as the whole reason for having "HOSTS" style is to use hosts.equiv, but since this is working I'm going to use it.

Kevin

rkiran · ‎2009-11-05

Its a bug in ONTAP and it seems to be fixed in ONTAP 7.3.2

kcollins · ‎2009-11-06

Thanks for that input! We are planning to upgrade fairly soon to 7.3.2 so that is good news.

I do have a question, though: if LOGIN works with hosts.equiv, what is the purpose of HOSTS?

Thanks,

Kevin

kcollins · ‎2009-11-06

Is it a bug also that a non-root user can use "LOGIN" type with "root" user and "" password and execute commands?

My script has:

our $s = NaServer->new($filer, 1, 1);
$s->set_style("LOGIN");
$s->set_admin_user("root", "");

And in the auditlog, I see:

Fri Nov 6 09:55:33 PST [cpafisnas1: HTTPPool04:debug]: root:AUTH:error:Login failed for user root from IP 146.27.78.190. reason "User not authenticated"
Fri Nov 6 09:55:33 PST [cpafisnas1: api_mpool_04:debug]: root:API:in:<?xml version='1.0' encoding='utf-8' ?><!DOCTYPE netapp SYSTEM 'file:/etc/netapp_filer.dtd'><netapp version='1.1' xmlns='http://www.netapp.com/filer/admin'><system-get-version></system-get-version></netapp>

The API authentication is failing and I am still able to execute the command - not good!

The behavior is the same on all of my systems (7.2.5.1 and 7.3.1.1).

Thanks,

Kevin

rkiran · ‎2009-11-09

Your script may not work with 7.2.5 release.

If the host on which you enter the command is a UNIX host, the user name is optional. If you do not specify a user name, you must be root on that host to execute any command.

I think when HOSTS style is set, client doesn't send user credentials to the ONTAP. ONTAP defaults the username to 'root' if it finds no user credentials sent across from client when hostequiv style authentication is enabled.If a client host name and a username is put in to /etc/hosts.equiv then this default switch is not going to happen.

Let us know if you still see the behaviour after upgrading to 7.3.2

kcollins · ‎2009-11-09

The script is working with BOTH 7.2.5.1 and 7.3.1.1, however it should be failing when not run by the root user.

The problem I am reporting is that when using the "LOGIN" style with user "root" and a null password, I am able to login even when the script is run as a non-root user. This means that even though my hosts.equiv specifically states "root", other users from that machine can perform functions via the API that they are not authorized to. If you see the auditlog entries from my previous message, you can see that the system is saying authorization failed but then allowing the command to run anyway!

This is has serious security implications...

Thanks,

Kevin

dussa · ‎2009-11-16

LOGIN style means that API requests are going to be authenticated using HTTP Basic authentication (ie., username and password). It really does not matter how you logged in to the client and running this script, but what matters is what credentials you passed in via API request. Filer does not use "/etc/hosts.equiv" file for authenticating these kind of requests.

To be specific, for LOGIN style authentication, pass in a valid Filer username and password to have authentication.

$s->set_style("LOGIN");

$s->set_admin_user($user, $pwd);

On the other hand, for HOSTS style authentication, clients must execute the script using "root" privilege to bind to any reserved port. Currently, Applications that use SDK cannot support hosts.equiv style authentication for non-root CLIENT users for APIs.

Please let me know if you have any questions.

Thanks,

Suresh

kcollins · ‎2009-11-17

If you read my previous post carefully, you will see that I have the style set to LOGIN, user set to "root" and password as "" (null). The auditlog clearly shows the authentication failing, but my command still runs! The command should NOT run because authentication has failed. This is a problem...

Kevin

rkiran · ‎2009-11-20

>> The auditlog clearly shows the authentication failing, but my command still runs! The command should NOT run because authentication has failed.
>> This is a problem...

This is not a vulnerability issue. Reason below:

When you enable "httpd.admin.hostsequiv.enable" option and sent an API request with LOGIN auth style(in your case user:passwd = root:""), ONTAP first authenticate the user using

HTTP basic authentication ie. using username and password. As this request failed due to password credentials mismatch , it logs an error in the auditlog.
Subsequently, it looks at "httpd.admin.hostsequiv.enable" option, and it did successfully authenticate the request as /etc/hosts.equiv was setup properly for this client.