We have our Isilon using AD as authenticator, when our Windows clients right click on a file to get the ownership of it, most of the time the username shows it's UID#, something like this: S-1-22-1-10514 (the last 5 digits being the unix UID as entered on the AD user's account under Unix attributes) instead of the user name.
When checking the UID # on the Isilon, we get:
isi01-1# isi auth users view --uid=10514
Failed to find user for 'UID:10514': No such user
The weird thing is that I can search by username and the Isilon finds it without a problem.
I know the username to who UID 10514 belongs to:
isi01-1# isi auth users view --user=user_name
Name: user_name
DN: CN=First Last, OU=Group_name,OU=Division,OU=Location,OU=Users,OU=PostUsers,DC=domain_name,
As you can see, querying the AD using the username instead of the UID #, the isilon finds the user correctly, it even lists the UID that just seconds ago was unable to find.
After querying by user_name, I now query again using the UID #, I get:
isi01-1# isi auth users view --uid=10514
Name: user_name
DN: CN=First Last, OU=Group_name,OU=Division,OU=Location,OU=Users,OU=PostUsers,DC=domain_name,
Yes, the two slashes are intentional; the first one is an escape character.
If the output of those 2 commands matches that's a really good starting point. Because of course the ideal configuration is that regardless of how a given user connects, they have the same username, UID, GID, SID, and supplemental secondary groups.
I ran both commands as you suggested and they both matched.
In this case, I ran your commands against an users that the Isilon was unable to find via its UID#.
After I ran your commands, I then did a search again the user's UID# and the Isilon found the user this time, as if the Isilon can't resolve the UID#, but once the user is searched via username, the Isilon now is aware of this user's UID#.
Select the Attributes folder, then in the right hand window pane, open the properties dialog box and ensure that the following check boxes are selected for each attribute listed below:CAUTION: Do not modify any other check boxes.
uid: Select the Replicate this attribute to the global catalog and the Index this attribute check boxes.
uidNumber: Select the Replicate this attribute to the global catalog and the Index this attribute check boxes.
gidNumber: Select the Replicate this attribute to the global catalog and the Index this attribute check boxes.
Active Directory Schema Snap-in example: The attributes are copied to the global catalog. Depending on your system configuration, this process might take up to 24 hours to complete.Phase 2: Add UIDs to accounts in Active Directory (if not already populated)
Log in to the Domain Controller.
Click Start > Administrative Tools > Active Directory Users and Computers.
Expand the domain and double-click the Users folder.
Double-click a user to which you want to add UIDs. The Properties dialog box opens.
Click UNIX Attributes tab.
Select a NIS Domain from the drop-down list.
Fill in the following boxes:
UID
Login Shell
Home Directory
Primary group name/GID
Click OK.
Repeat Steps 5- 9 for each user.
This process could also be accomplished for a large number of users and groups with a script based on the information from the Microsoft pages below:
For us all it took was to set the AD schema to replicate these items since we already have populated the user's accounts and groups with the proper uid, uidNumber & gidNumber. After the replication was done (which it took several hours because our AD is so big) the Isilon and all windows machines were able to resolve the uid's without any problem!
I hope this helps someone else experiencing these issues.
I get this as well on some users. I tried to change one ownership on a file share and it went back to the s-1-22-1-uid#.
The attributes are coming over and matching. I can't get it to the domain\\username. The uid# does not resolve to the username on the Isilon. We did the RF2307 a few years ago and that fixed users, but few still exist. Is there a cache somewhere?
crklosterman
450 Posts
4002
0
Posted February 17th, 2017 06:00
Hector,
First thing is that you want to when troubleshooting, use a different command.
'isi auth mapping token domain\\username --zone= '
&
'isi auth mapping token username --zone= '
Yes, the two slashes are intentional; the first one is an escape character.
If the output of those 2 commands matches that's a really good starting point. Because of course the ideal configuration is that regardless of how a given user connects, they have the same username, UID, GID, SID, and supplemental secondary groups.
~Chris Klosterman
Principal SE, Datadobi
chris.klosterman@datadobi.com