Assuming you are using NIS for NFS3, there it no "authorization" involved when the clients connect to the server.

Therefore your plan is pretty easy to set up. HOWEVER you will run into problems as soon as the same numerical user id appears in  both A and B but for two different users, or vice versa.

-- Peter

Hi Peter, Thanks for your reply. Yes, this customer do have users which are common across both the domains. Thus there are username conflicts. These users have same username but different UID/GIDs across the two domains. This is not an issue on the client side as domain A workstations only see UID/GID corresponding to domain A and vice versa. Also note that due to the business policy which says that all the users except data management users should not be able to see the data across business units or in other words, the workstations/clients that belong to domain A only has domain A specific mount points and domain B clients only have domain B specific mount points. Also this customer has a standardization that the mount points are mounted using root through /etc/fstab on clients which are Linux (ver 3, 4 and 5) and Solaris (ver 9 and 10).

This possible could be an issue if they use users other than root to mount the mount points which is not the case as they use root. So in domain C, we maintain both the identities of the conflicting users. For eg a user X has uid/gid in domain A as 100/10 and in domain B has 900/90. The domain C will have two maps passwd.byname and passwd.byuid. And it will contain both the uid/gid. Thus when a lookup is done for uid 100 or 900 in domain C, both the queries will give the username userX. For customer, the user identity in domain A is important and they are ok to discard the identity in domain B. That is from the above example, use the identity 100/10 and discard 900/90. If we do this, we will have to change the uid/gid 900/90 to 100/10 and then chown the files. But we don`t want to do this as there are legacy applications which store the username and uid/gid inside the application database and config files and the moment we change these, it may break the application and the application vendor doesn`t guarantee smooth operations.

Also, YES, ALL THE MOUNT POINTS ARE USING NFS3.

So based on the above information, will this solution still be valid? Thanks a bunch for your help, appreciate it!

Cheers!!

Relevant for NFS3 operations are only the numerical IDs. Collisions here would be the larger problem, though things might go well at first sight. But quotas wouldn't work as expected if a quota domain covers exports for both A and B. And if there are have users with more that 16 groups, and therefore NFS exports are  configured to do the group lookups of the Isilon side(!), a user could obtain the group memberships from the sibling in the other domain.

The analysis for collisions of textual user names looks pretty plausible to me. Just beware of fancy extra "id mappings" steps one might do on the Isilon later on, or inclusion of SMB sharing. It can get really hard to track the actual functions of permission, quotas, etc when mappings are involved plus ambiguities exists.

Best of luck!

-- Peter

Hi Peter, thanks a bunch for your response and help. I am not worried about the numerical ID conflicts as there are no users who`se id is taken by another user. Also, if I remember correct this customer doesn`t have smart quotas enabled so that part is sorted out for me too, I`ll double check to be sure.

Wondering what do you mean by "fancy extra id mappings steps one might do on the Isilon later on... ".

Thanks again for your help, really appreciate it!

Cheers!

The bottom line, or maybe it should have been the head line, is that

for NFS3 the (any) server doesn't rely on NIS (or LDAP or whatever)

user lookups at all for serving the clients.

It is a mere convenience to have the user names available on the

server, for comprehensive output of a simple "ls -l" as well as  quotas and InsightIQ

(which would work with numerical IDs otherwise). Also ACLs are usually

written with user names.

Therefore all considerations mentioned arise from additional functions inside

the server, where textual user names are appreciated; or where explicit lookups

are requested (groups for user -- actually a cheat on the NFS protocol),

or where mapping rules involving user names need to be used.

If you haven't run across identity mapping in OneFS until now,

that has saved you a lot of complexity... It appears simple

and powerful, but requires careful planning and implementation,

just like for example ACLs.

Mapping can become handy if you want to declare different identities/personas

from different sources as equivalent. Sources can be: On disk ownerships,

OneFS cluster local accounts, MIS, LDAP, AD.) Once you learn about it

(See Admin Guides and the Multiprotocol White paper; don't confuse

identity mapping and permission mapping), it might be become tempting

to use it for all sorts of fixes to "legacy" id constellations. Just be warned,

there is a Pandora's Box to be opened...

Cheers

-- Peter

Peter, one more question on Isilon ID mappings. Can I establish and equivalence among two NIS users from the same NIS domain? Can I say a users with uid/gids 900/90 and 100/10 are equivalent (if not the same) and should enjoy the same ownership and access privileges?

Are these mappings permanent or a flush can erase them?

Thanks!

The "mappings" are what is in effect at the moment, and are in some sort of cache.

The are created by  "rules" which are a static configuration.

It's really a Pandora's Box I probably shouldn't have opened in this thread...

Please check out the (present and upcoming) documents mentioned here,

and the wonderful postings of the Tim Wright, the hosting Expert of this session:

Ask the Expert: AIMA: Everything you wanted to know but were afraid to ask.

(AIMA = Authentication, Identity Management, and Authorization)

-- Peter