Authenticate as LDAP user to connect to a cluster from a Red Hat server

[Smurfy.]

Hello,

We have a cluster of NL400 nodes running OneFS 6.5.x, with an NFS file system and Windows permissions.  We also have a virtual machine running Red Hat that we're trying to use to connect to the Isilon cluster, to run Python scripts for reporting, etc.

Our IT department (who have direct access to the Isilon cluster) have allowed our Red Hat server's IP to be allowed to mount the Isilon shares from the /ifs point.  

Here's the issue -- We use LDAP to authenticate to the Isilon, and while I am authenticated into the Red Hat server by the same LDAP account that should let me into the Isilon, I have no permission to get into the shares themselves.  I'm guessing that I'm identified as being logged into LDAP.  A guy in our IT department told me that he seemed to remember reading some Isilon help documents about basically forcing a second LDAP authentication when connected to the mount like this as the way to get into the cluster, but unfortunately, could not remember where he'd read it or give any helpful keywords in trying to find it.  I'm not sure if he was referring to an isi command or something else, but I've so far had no luck finding an authentication method like the one he describes (or any at all).

Does anyone know of a way to force another LDAP authentication from a virtual server when you're already logged in, to authenticate to Isilon? 

Thanks,

-S

[Peter Serocka]

On 2013 Aug 1. md, at 02:22 st, Smurfy. wrote:

> Does anyone know of a way to force another LDAP authentication from a virtual server when you're already logged in, to authenticate to Isilon?

Assuming you use NFS3, there is no such thing like
"authentiate to Isilon" during NFS file access;
it is much simpler as follows:

On your client you use a login name, and obtain a
numerical user id (uid) from the LDAP.

When you access an NFS share, the Isilon sees
your uid (that plain number) and matches
it with the owner (also plain uid) and related permissions,
as well as ACLs if present, of the accessed file and
its parent dirs up to the share's export/mount point.

Similar for the groups that your login is associated with,
they carry names and numerical ids (gid), but read on.

You expect to access (presumably large) content under
the mounted /ifs from a single user name/uid - how exactly is that
supposed to work? (User is not root, right?)

Have suitable ACLs been set up for you?

If so, does it work when you log in (ssh) to the Isilon directly?
(here "authenticate to Isilon" via LDAP makes sense, but has nothing
to do with NFS or Windows.)

If it works on the Isilon, but not on the NFS clients,
double check wether the accounts on Isilon and Linux
are identical by numerical(!) uid and gids ("id" command).

Further understanding of using ACLs for combining Windows permissions
(which you have mentioned) and Unix permissions on the same shares
can be found in this excellent document:

White Paper
EMC ISILON MULTIPROTOCOL DATA ACCESS WITH A UNIFIED SECURITY MODEL
August 2012
http://www.emc.com/collateral/software/white-papers/h10920-wp-onefs-multiprotocol.pdf

Some additional thoughts:

If your permission settings actually rely on *groups*
(either with ACLs or with classical Unix permissions),
there are two caveats:

- when associating users to groups by group names,
these names might get resolved to gids by
system-local group definitions, not the LDAP.
For example, "staff", "admin", and "www" groups are
often defined locally, usually overriding LDAP definitions.
So for example if your plan is to access some
folders through permissions granted to group "staff",
and "staff" were represented by gid 777 on Isilon,
888 on Linux, and 999 in LDAP, then confusion will be guaranteed.
Make sure the relevant gids are consistently defined
in the first place, or better use groups exclusively
(by name as well as by gid!) defined in the LDAP.

- If your account needs to associated be with
more than 16(!) groups to make your plan work,
beware that NFS clients only transmit
up to 16 gids to the NFS server...
Solution: On the Isilon, set "Map lookup UID" to "yes"
under Advanced Settings at the /ifs export's settings.
By this, the Isilon will retrieve all (>16)
gids that your login has from the LDAP, rather than
only 16 gids through NFS from the client.

One more thing...

For your reporting, do you plan to scan
the whole Isilon cluster at regular intervals?

With say 100 million files you might not
get happy with the performance, even
with NFS readdirplus(!) properly enabled,
and with metadata on SSD (not your NL400 actually).
Might be ok with 100 thousand files...

The NFS overhead can be simply too high,
and wastes performance missing for other clients.

I'd consider scanning the Isilon locally,
with a simple IT-friendly ;-) one-liner using
du, ls -lR, "find . -ls" or the like.
(Using find and stat together might trigger issues
with lsassd -- more on this when needed.)

All report processing could then be done
on the Linux server, parsing the plain
output file(s) from the scanning phase.


Hope this helps - good luck!

-- Peter

> --
> You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Peter Serocka
CAS-MPG Partner Institute for Computational Biology (PICB)
Shanghai Institutes for Biological Sciences (SIBS)
Chinese Academy of Sciences (CAS)
320 Yue Yang Rd, Shanghai 200031, China
pser...@picb.ac.cn