NFS Auditing... Almost

[joe_kraska]

Hi,

We have auditing for NFS working on our filers... sort of.

The basic issue involves mapping a unix identity to something windows can understand.

For example, suppose the following two use cases:

1. joe.user (uid=1001) on the unix side, and MYDOMAIN\joe.user on the windows side;

    in this use case, joe.user exists in a linux LDAP system

2. nancy.user (uid=2001) on the unix side, with no account on the windows side

    in this use case, the user only exist on a linux virtual machine, and is absconding away with a UID they shouldn't be

We can successfully get our netapps to log insofar as either the local passwd file on the netapp has a UID-to-name mapping for joe.user, or our linux LDAP system has such an entry.

However, we cannot get the system to work for use case 2.

We tried putting:

MYDOMAIN\nobody <=*

... into the usermap.cfg file, which is to say "map any unknown user to the domain user 'nobody'," however this apparently does not want to work unless first a name mapping can somehow be found for a user.

As it turns out, I don't really care about the user, as the audit event I am interested in is the IP address of the offending box only.

Is there a way to disable the usermap portion of the audit entirely?

[psean]

According to the How To (How to set up NFS auditing) on the NOW site, the only way NFS auditing will work is with UNIX userids mapped to valid Windows userids.

[joe_kraska]

Very well. However, at first blush, the following map:

MYDOMAIN\nobody <= *

... should map any unix user to the domain account "nobody". However, it fails.

I believe that this is because when an arbitrary unix uid comes in, the usermap.cfg file first wants to convert it to text before doing the map.

This should not be necessary in this case.

Is there any way around it?

Joe.

[psean]

Joe,

I'll look into this deeper for you as I have time. Could you please tell me what version of ONTAP the filer is running, and is the entry you made to the usermap.cfg the first one in the list?

[joe_kraska]

OnTap 7.3.4, and the entry was the only entry in the list.

Thank you.

Joe.

[aborzenkov]

To my best knowledge UID-to-name mapping is mandatory in mixed multiprotocol environment (see as example description of authentication flow in tr-3490).

From your description it looks more like administrative than technical problem, really. Simple question – how will you distinguish between different nancy.users with the same UID coming from different client?

May be some clever use of NFSv4 with its identity mapping could help in this case.

[joe_kraska]

We have a very large (almost 2,000) number of virtual machines in our environment. In some cases, rogue users have created local accounts with unauthorized uid's.

This has always been a bit of a headache, and from a certain perspective the "access denied" result of no name mapping would be a feature if we were rolling out the system from scratch. However, we're not, and abruptly cutting off the rogues at the knees is not in our current plan.

To answer you're question... how will we know?... the main information of interest to us in the audit record of is the IP address of the offending machine. While it would be nice to know the user, in the event that we cannot know the user I would still like the IP address of the audit. It would be very helpful. The information is actually present, and while the OnTap auditing code may not do the right thing here, it would be a shame if it couldn't, as it is failing to provide us with information that it has. Basically what I am saying is that I want the ability to do an absolute fall-back (to wit: "if the user is not known, let them have access, but audit them as 'nobody'"). Again, it's the IP address of the event that I care about.

It's not a security issue, either. There isn't any such thing as NFSv3 security once you have to trust the remote host (as we do).

As an aside, we have LDAP, and the majority of our users actually map correctly to that. But we need to permit access to the rogues even as we audit them.

Joe.

[aborzenkov]

I wonder if it is possible to hack LDAP server to provide fallback reply in case of unknown UID.

[loudymanschwab]

Had a similar issue with NFS auditing.  Ended up creating a local user account on the filer in the Guest group, and then placed this user in wafl.default_nt_user.  Then for any user than cannot map to a "Windows" account either via LDAP (or whatever nsswitch methods you are using) or usermap.cfg, it defaults to this account and successfully logs an entry with this username and the host IP.  Since the user is a Guest which is not in any of our NTFS permissions, this also means that I did not accidentally elevate their rights to any NTFS based data (and with 7.3+ it seems like the user has to be in a group to be able to make them...maybe you can remove from group after creation).

Also found that if you utilize fsecurity to set audit settings on a specific vol, qtree, folder, etc, and left audit settings on the cifs.audit.nfs.filter.filename file as completely blank that you can limit which filesystems you actually audit with NFS.