Unsolved
This post is more than 5 years old
1 Rookie
•
4 Posts
0
5849
February 16th, 2017 15:00
Windows AD/UID # not resolving.
Hello,
We're running OneFS ver 8.0.0.2
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,
DNS Domain: domain_name
Domain: domain
Provider: lsa-activedirectory-provider:domain
Sam Account Name: user_name
UID: 10514
SID: S-1-5-21-2214466714-34022394616-30948320520-24450
Enabled: Yes
Expired: No
Expiry: -
Locked: No
Email: user_name@mycompany.com
GECOS: -
Generated GID: No
Generated UID: No
Generated UPN: No
Primary Group
ID: GID:100
Name: group_name
Home Directory: /home/post/user_name
Max Password Age: -
Password Expired: No
Password Expiry: -
Password Last Set: 2016-12-05T12:31:38
Password Expires: Yes
Shell: /bin/tcsh
UPN: user_name@domain_name
User Can Change Password: Yes
----------------------------------
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,
DNS Domain: domain_name
Domain: domain
Provider: lsa-activedirectory-provider:domain
Sam Account Name: user_name
UID: 10514
SID: S-1-5-21-2214466714-34022394616-30948320520-24450
Enabled: Yes
Expired: No
Expiry: -
etc, etc, etc.
So it appears that by running the query a second time, the isilon finds the user without a problem because the query is now cached.
Any idea why this is happening?
Is there a way to "flush" the isis AD lookup cache?
Please advise and thanks.
Hector Barrera.



crklosterman
450 Posts
0
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
hectorb21
1 Rookie
•
4 Posts
0
February 17th, 2017 10:00
Thanks Chris for your reply.
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#.
I should mention this happens on some users only.
Thanks!
Hector B.
hectorb21
1 Rookie
•
4 Posts
0
February 21st, 2017 10:00
I believe we found the solution.
It appears that our AD was not set to replicate the uid, uidNumber & gidNumber among the AD controllers.
I found this information on the DellEMC site how to configure AD to replicate the above:
Link the the original article: https://emcservice.force.com/CustomersPartners/kA2j0000000QXfYCAW
Configure Active Directory
Configure Active Directory to allow search queries on UID, GID, and Alias by publishing RFC 2307 attributes to the global catalog:
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)
Phase 3: Add GIDs to accounts in Active Directory (if not already populated)
--------------------------
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.
Hector B.
shell1511
2 Posts
0
March 8th, 2023 15:00
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?
DELL-Josh Cr
Moderator
•
9.4K Posts
0
March 9th, 2023 07:00
Hi,
Thanks for your question. What version of OneFS are you using? These many be helpful. https://dell.to/3l1jBDy and https://dell.to/3Favzl9
Let us know if you have any additional questions.