Unsolved

This post is more than 5 years old

1 Rookie

 • 

4 Posts

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.

450 Posts

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

1 Rookie

 • 

4 Posts

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.

1 Rookie

 • 

4 Posts

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:

  1. Log on to Windows Server Active Directory using the Administrator account.
  2. Load the Active Directory Schema Snap-in.Note: To install the Active Directory Schema Snap-in, see the following Microsoft TechNet articles:
  3. 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:
             
AD Schema Snap-in Attribute ExampleThe 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)

  1. Log in to the Domain Controller.
  2. Click Start > Administrative Tools > Active Directory Users and Computers.
  3. Expand the domain and double-click the Users folder.
  4. Double-click a user to which you want to add UIDs. The Properties dialog box opens.
  5. Click UNIX Attributes tab.
  6. Select a NIS Domain from the drop-down list.
  7. Fill in the following boxes:
    • UID
    • Login Shell
    • Home Directory
    • Primary group name/GID
  8. Click OK.
  9. Repeat Steps 5- 9 for each user.
  10. 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:
    1. https://technet.microsoft.com/en-us/library/bb463169.aspx
    2. https://technet.microsoft.com/en-us/library/bb463193.aspx
    3. http://blogs.msdn.com/b/sfu/archive/2010/03/31/synchronizing-sfu-attributes-with-rfc2307-attributes.aspx
    4. http://blogs.technet.com/b/sfu/archive/2011/05/25/scripts-to-populate-the-unix-attributes-when-migrating-from-sfu-3-5-to-rfc-2307-schema.aspx

Phase 3: Add GIDs to accounts in Active Directory (if not already populated)

  1. Log in to the domain controller.
  2. Click Start > Administrative Tools > Active Directory Users and Computers.
  3. Click Groups, or the folder (container) in which the group resides if no Groups folder present.
  4. Double-click a group to which you want to add GIDs.
  5. Click the UNIX Attributes tab.
  6. Select a NIS Domain from the drop-down list.
  7. Enter a GID [Group ID] in the field.
  8. Click Add.
  9. Select members to add to the group.
  10. Click Add.
  11. Click OK.
  12. Again, click OK.
  13. 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.
    1. https://technet.microsoft.com/en-us/library/bb463169.aspx
    2. https://technet.microsoft.com/en-us/library/bb463193.aspx
    3. http://blogs.msdn.com/b/sfu/archive/2010/03/31/synchronizing-sfu-attributes-with-rfc2307-attributes.aspx
    4. http://blogs.technet.com/b/sfu/archive/2011/05/25/scripts-to-populate-the-unix-attributes-when-migrating-from-sfu-3-5-to-rfc-2307-schema.aspx

--------------------------

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.

2 Posts

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?

Moderator

 • 

9.4K Posts

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.

No Events found!

Top