how do I get isilon to look up numeric UIDs in active directory?

[Dan Pritts]

Hi all -

I'm trying to use --map-lookup-uid to have the isilon look up group memberships itself, rather than using the group membership sent as part of the NFS request. 

I've got an immediate need for this:  a user in more than 16 unix groups.   Also, I want to do this going forward so that we can just maintain groups in AD and not worry about it on Linux. 

The --map-lookup-uid setting is working properly.

However....

We have a campus-wide Active Directory forest that i've bound the Isilon cluster to.  The cluster has no other authentication providers configured, except for mostly-empty "LOCAL" and "FILES" providers. 

uidNumber and gidNumber are available in AD.

things work fine if I prime the auth mapping cache with:

    isi auth mapping list --source-user username

This populates the cache so that system knows about the UID<=>username mapping.   The user can write to folders that he's acl'd to, etc. 

If i then

    isi auth mapping flush --all

the user is no longer able to write to said folders. 

/var/log/lsassd.log then has something like the following:

    lsassd[7817]: [lsass] Failed to map token token={UID:3291, GID:2000586020, GROUPS={GID:27, GID:8888, [...] , GID:2000586118}, zone id=-1 }: Failed to lookup uid 3291: LW_ERROR_NO_SUCH_USER

So...my question is, how do I get the system to look in AD to do that UID lookup?

I have tried this:

    isi auth ads modify MYDOMAIN --nss-enumeration true
    isi auth ads reload

Unfortunately, it doesn't seem to have made any difference. 

I can do an LDAP query against AD, directly, and it will do this sort of lookup. 

Any thoughts?

thanks
danno

--
Dan Pritts
ICPSR Computing & Network Services
University of Michigan
+1 (734)615-7362

[Peter Serocka]

isi auth mapping token -v --name=username

gives a more comprehensive picture IMO.

You don't have set any explicit mapping rules configured on the Isilon?

The AD is bound in which zone?

Those listed groups GROUPS={GID:27, GID:8888, [...] , GID:2000586118} are (only) the first 16 unix groups
from the NFS request?

It might be simply the case that --map-lookup-uid (NFS) doesn't work with AD in a separate zone...

-- 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.

[Dan Pritts]

isi auth mapping token -v --name=username gives a more comprehensive picture IMO.

With that, I am told that there is no such user.

Unless, of course, I prime the cache with the same good old

     isi auth mapping --source-user=username

which picks it all up from AD. 

You don't have set any explicit mapping rules configured on the Isilon?

No mapping rules.  The usernames in AD are unix-compatible, and AD has all the information we need - users, uids, groups, gids.  It mostly works, except for this one little wrinkle.

The AD is bound in which zone?

All of them, actually. 

Those listed groups GROUPS={GID:27, GID:8888, [...] , GID:2000586118} are (only) the first 16 unix groups
from the NFS request?

yes.

[Keith Nargi]

When you do the isi auth mapping token make sure you include the domain with the user name 

Isi auth mapping token --username=mydomain\\knargi will show you both uid and Sid if the user is in that ad

--

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.

--
Keith 

[Keith Nargi]

That was suppose to be --name not username sorry bout that 

--
Keith 

[Dan Pritts]

Yeah, that works.  thanks.

Doesn't really affect my issue, though - to be clear, my problem is that UIDS are not getting mapped back to names.  The name->uid mapping works fine. 

thanks
danno

Keith Nargi

October 9, 2013 9:40 PM

That was suppose to be --name not username sorry bout that 

On Wednesday, October 9, 2013, Keith Nargi wrote:

--
Keith 

--
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.

Keith Nargi

October 9, 2013 7:43 PM

When you do the isi auth mapping token make sure you include the domain with the user name 

Isi auth mapping token --username=mydomain\\knargi will show you both uid and Sid if the user is in that ad

On Wednesday, October 9, 2013, Dan Pritts wrote:

--
Keith 

--
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.

Dan Pritts

October 9, 2013 5:03 PM

isi auth mapping token -v --name=username gives a more comprehensive picture IMO.

With that, I am told that there is no such user.

Unless, of course, I prime the cache with the same good old

     isi auth mapping --source-user=username

which picks it all up from AD. 

You don't have set any explicit mapping rules configured on the Isilon?

No mapping rules.  The usernames in AD are unix-compatible, and AD has all the information we need - users, uids, groups, gids.  It mostly works, except for this one little wrinkle.

The AD is bound in which zone?

All of them, actually. 

Those listed groups GROUPS={GID:27, GID:8888, [...] , GID:2000586118} are (only) the first 16 unix groups
from the NFS request?

yes.

Peter Serocka

October 9, 2013 2:49 PM

isi auth mapping token -v --name=username

gives a more comprehensive picture IMO.

You don't have set any explicit mapping rules configured on the Isilon?

The AD is bound in which zone?

Those listed groups GROUPS={GID:27, GID:8888, [...] , GID:2000586118} are (only) the first 16 unix groups
from the NFS request?

It might be simply the case that --map-lookup-uid (NFS) doesn't work with AD in a separate zone...

-- Peter

Dan Pritts

October 9, 2013 2:02 PM

Hi all -

I'm trying to use --map-lookup-uid to have the isilon look up group memberships itself, rather than using the group membership sent as part of the NFS request. 

I've got an immediate need for this:  a user in more than 16 unix groups.   Also, I want to do this going forward so that we can just maintain groups in AD and not worry about it on Linux. 

The --map-lookup-uid setting is working properly.

However....

We have a campus-wide Active Directory forest that i've bound the Isilon cluster to.  The cluster has no other authentication providers configured, except for mostly-empty "LOCAL" and "FILES" providers. 

uidNumber and gidNumber are available in AD.

things work fine if I prime the auth mapping cache with:

    isi auth mapping list --source-user username

This populates the cache so that system knows about the UID<=>username mapping.   The user can write to folders that he's acl'd to, etc. 

If i then

    isi auth mapping flush --all

the user is no longer able to write to said folders. 

/var/log/lsassd.log then has something like the following:

    lsassd[7817]: [lsass] Failed to map token token={UID:3291, GID:2000586020, GROUPS={GID:27, GID:8888, [...] , GID:2000586118}, zone id=-1 }: Failed to lookup uid 3291: LW_ERROR_NO_SUCH_USER

So...my question is, how do I get the system to look in AD to do that UID lookup?

I have tried this:

    isi auth ads modify MYDOMAIN --nss-enumeration true
    isi auth ads reload

Unfortunately, it doesn't seem to have made any difference. 

I can do an LDAP query against AD, directly, and it will do this sort of lookup. 

Any thoughts?

thanks
danno

--
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]

An excellent start for more info is the recent session

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

(Authentication, Identity Management, and Authorization)

https://community.emc.com/thread/180928

It has pointers to relevant docs (however, the promised

AIMA idmapper paper isn't available yet) and also

Tim Wright's excellent introduction and and further postings are well worth reading.

For example it becomes clear that "mappings" are what is effective now

and live the the cache. But they are created from "rules" which are permanent

(configurable). This explains your experience at least partly.

If you can pull the desired gid lookups into the cache manually,

but not "on the fly" by an NFS request, that would make

for an SR call I think.

-- Peter

On Fri 11 Oct '13 md, at 00:34 st, Dan Pritts <da...@umich.edu> wrote:

Yeah, that works.  thanks.

Doesn't really affect my issue, though - to be clear, my problem is that UIDS are not getting mapped back to names.  The name->uid mapping works fine.  

thanks
danno

Keith Nargi October 9, 2013 9:40 PM
That was suppose to be --name not username sorry bout that 

On Wednesday, October 9, 2013, Keith Nargi wrote:


-- 
Keith 
-- 
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-group+un...@googlegroups.com.

To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-group+un...@googlegroups.com.

[Dan Pritts]

Sort of -

when i have an empty cache, nfsd tries to look up a user by UID, to get the username back.  If it has the username, it can then evaluate an ACL to see if the user has access.  However, the UID->name lookup fails, and the user is denied. 

If I do a name->UID lookup manually from the command line, it works.  The combo is now in the cache, so any subsequent UID->name lookup by nfsd succeeds.  At least until the cache times out, which happens pretty quick.

I do have an SR open, but their first answer was to create mapping rules for each user.  Which is certainly a solution, but it's not a very good one.

I will check out the link you sent, thanks.

danno

Peter Serocka

October 10, 2013 1:05 PM

An excellent start for more info is the recent session

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

(Authentication, Identity Management, and Authorization)

https://community.emc.com/thread/180928

It has pointers to relevant docs (however, the promised

AIMA idmapper paper isn't available yet) and also

Tim Wright's excellent introduction and and further postings are well worth reading.

For example it becomes clear that "mappings" are what is effective now

and live the the cache. But they are created from "rules" which are permanent

(configurable). This explains your experience at least partly.

If you can pull the desired gid lookups into the cache manually,

but not "on the fly" by an NFS request, that would make

for an SR call I think.

-- Peter

On Fri 11 Oct '13 md, at 00:34 st, Dan Pritts <da...@umich.edu> wrote:

--
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.

Dan Pritts

October 10, 2013 12:34 PM

Yeah, that works.  thanks.

Doesn't really affect my issue, though - to be clear, my problem is that UIDS are not getting mapped back to names.  The name->uid mapping works fine. 

thanks
danno

Keith Nargi

October 9, 2013 9:40 PM

That was suppose to be --name not username sorry bout that 

On Wednesday, October 9, 2013, Keith Nargi wrote:


--
Keith 
--
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.

[Peter Serocka]

Posting 13 (behind the link) talks about map-lookup-uid, and it will make you… [dunno].

Point your SR owner to that.

Posting 10 is fascinating in that is shows mapping rules with wildcards ;-)

Enjoy!

-- Peter

To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-group+un...@googlegroups.com.