Bug 12410 - Unable to convert SID ... at index 2 in user token to a GID
Summary: Unable to convert SID ... at index 2 in user token to a GID
Status: RESOLVED INVALID
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.5.1
Hardware: All Linux
: P5 critical (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL:
Keywords:
: 12393 (view as bug list)
Depends on: 12155
Blocks:
  Show dependency treegraph
 
Reported: 2016-11-07 11:45 UTC by Tisheng Chen
Modified: 2021-01-17 10:50 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tisheng Chen 2016-11-07 11:45:51 UTC
Recently, we tried to upgrade our samba server from 4.4.5 to 4.5.1. After the
upgrade, users could not access network shares any more. From the debug log,
we got some lines as follows.
============================================
[2016/11/07 19:37:57.531974,  0] ../source4/auth/unix_token.c:107(security_token_to_unix_token)
  Unable to convert SID (S-1-5-21-2210662606-1361898417-2692578642-1110) at index 2 in user token to a GID.  Conversion was returned as type 0, full token:
[2016/11/07 19:37:57.532190,  0] ../libcli/security/security_token.c:63(security_token_debug)
  Security token SIDs (19):
    SID[  0]: S-1-5-21-2210662606-1361898417-2692578642-1108
    SID[  1]: S-1-5-21-2210662606-1361898417-2692578642-513
    SID[  2]: S-1-5-21-2210662606-1361898417-2692578642-1110
    SID[  3]: S-1-5-21-2210662606-1361898417-2692578642-1112
    SID[  4]: S-1-5-21-2210662606-1361898417-2692578642-1113
    SID[  5]: S-1-5-21-2210662606-1361898417-2692578642-1118
    SID[  6]: S-1-5-21-2210662606-1361898417-2692578642-1117
    SID[  7]: S-1-5-21-2210662606-1361898417-2692578642-1114
    SID[  8]: S-1-5-21-2210662606-1361898417-2692578642-1121
    SID[  9]: S-1-5-21-2210662606-1361898417-2692578642-1115
    SID[ 10]: S-1-5-21-2210662606-1361898417-2692578642-1102
    SID[ 11]: S-1-5-21-2210662606-1361898417-2692578642-1160
    SID[ 12]: S-1-5-21-2210662606-1361898417-2692578642-1161
    SID[ 13]: S-1-1-0
    SID[ 14]: S-1-5-2
    SID[ 15]: S-1-5-11
    SID[ 16]: S-1-5-32-548
    SID[ 17]: S-1-5-32-545
    SID[ 18]: S-1-5-32-554
   Privileges (0x          800000):
    Privilege[  0]: SeChangeNotifyPrivilege
   Rights (0x             401):
    Right[  0]: SeInteractiveLogonRight
    Right[  1]: SeRemoteInteractiveLogonRight
[2016/11/07 19:37:57.533237,  3] ../source3/smbd/smb2_server.c:3097(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_INVALID_SID] || at ../source3/smbd/smb2_sesssetup.c:134
[2016/11/07 19:37:57.533865,  3] ../source3/smbd/server_exit.c:246(exit_server_common)
  Server exit (NT_STATUS_CONNECTION_RESET)
====================================================================

It turned out to be related to rfc2307 for idmap. When some groups a user belong to have no UNIX group id (gidNumber) assigned, the error is triggered. In our system, we indeed only assigned UNIX group id to a few groups, not all. That is not an issue before the upgrade to 4.5.1.

We didn't do a thorough analysis of the bug. But we found a temporary fix as follows.
===================================
--- samba-4.5.1_orig/source4/auth/unix_token.c  2016-08-11 15:51:04.000000000 +0800
+++ samba-4.5.1/source4/auth/unix_token.c       2016-11-03 16:43:00.963452309 +0800
@@ -101,14 +101,14 @@
                    ids[s].xid.type == ID_TYPE_GID) {
                        (*sec)->groups[g] = ids[s].xid.id;
                        g++;
-               } else {
+               } /*else {
                        char *sid_str = dom_sid_string(mem_ctx, ids[s].sid);
                        DEBUG(0, ("Unable to convert SID (%s) at index %u in user token to a GID.  Conversion was returned as type %d, full token:\n",
                                  sid_str, (unsigned int)s, (int)ids[s].xid.type));
                        security_token_debug(0, 0, token);
                        talloc_free(sid_str);
                        return NT_STATUS_INVALID_SID;
-               }
+               }*/
        }
 
        DEBUG(5, ("Successfully converted security token to a unix token:"));
====================================
Comment 1 Andrew Bartlett 2016-11-07 18:24:00 UTC
Can you show me your current smb.conf?
Comment 2 Tisheng Chen 2016-11-08 01:47:18 UTC
Here's my smb.conf
================================
# Global parameters
[global]
    workgroup = XX
    realm = XX.XX.XX
    netbios name = XXX
    server role = active directory domain controller
    #server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
    server services = -dns

    idmap_ldb:use rfc2307 = yes

    idmap config * : range = 100000 - 33554431
    idmap config RD : backend   = ad
    idmap config RD : schema_mode  = rfc2307
    idmap config RD : range     = 10000 - 49999

    #idmap cache time = 10

    winbind nss info = rfc2307
    #winbind use default domain = yes
    winbind enum users = yes
    winbind enum groups = yes
    winbind refresh tickets = yes

    winbind offline logon = yes

    template shell = /usr/sbin/nologin
    template homedir = /home/%U

    interfaces = lo eth0
    bind interfaces only = true

    load printers = no

    log file = /usr/local/samba/var/log/%m.log
    #log level = 3

    create mask = 0750
    directory mask = 0750

[netlogon]
        path = /usr/local/samba/var/locks/sysvol/XX.XX.XX/scripts
        read only = No

[sysvol]
        path = /usr/local/samba/var/locks/sysvol
        read only = No

[public]
    path = /work/public
    read only = No
Comment 3 Andrew Bartlett 2016-11-08 08:52:27 UTC
Can you please revert
https://bugzilla.samba.org/attachment.cgi?id=12373
from
https://bugzilla.samba.org/show_bug.cgi?id=12155
patch -p1 -R < attachment.cgi\?id\=12373

And try again?

I strongly suspect that your (incorrect) idmap configuration statements are causing the issues, but I want you to try patching the code, not just the config file, as I may need to ask that this patch be reverted so as not to break upgrades.

A 'net cache flush' may be required.
Comment 4 Tisheng Chen 2016-11-08 09:13:26 UTC
Andrew, the patch solved the problem.
Comment 5 Andrew Bartlett 2016-11-08 17:52:02 UTC
*** Bug 12393 has been marked as a duplicate of this bug. ***
Comment 6 Stefan Metzmacher 2016-11-09 10:30:18 UTC
(In reply to Andrew Bartlett from comment #5)

Does just removing the invalid:

    idmap config * : range = 100000 - 33554431
    idmap config RD : backend   = ad
    idmap config RD : schema_mode  = rfc2307
    idmap config RD : range     = 10000 - 49999

options also fix the problem?
Comment 7 Stefan Metzmacher 2016-11-09 10:36:20 UTC
(In reply to Stefan Metzmacher from comment #6)

Or just remove this line:
idmap config * : range = 100000 - 33554431
Comment 8 Stefan Metzmacher 2016-11-09 11:10:57 UTC
(In reply to Stefan Metzmacher from comment #7)

If RD is your primary domain you should also remove

    idmap config RD : backend   = ad
    idmap config RD : schema_mode  = rfc2307
    idmap config RD : range     = 10000 - 49999
Comment 9 Tisheng Chen 2016-11-12 16:40:11 UTC
(In reply to Stefan Metzmacher from comment #8)
Removing the config lines you pointed out solves the problem, too.
Comment 10 Louis 2016-12-20 13:41:49 UTC
(In reply to Andrew Bartlett from comment #3)

I posted on the list, but upgraded 4.4.5 to 4.5.3. 
( yes including the idmap config still in smb.conf ) 

Removed the idmap parts the day after, rebooted the server, but only after the net cache flush it worked as normal again. 

so removing all : idmap config parts and running net cache flush fixed this for me. 

Debian Jessie, samba 4.5.3-Debian ( own (re)build debian package )
Comment 11 Louis 2016-12-20 15:41:26 UTC
(In reply to Stefan Metzmacher from comment #6 and #7)

I tested a bit more. 

It works fine with : 
        idmap config * : backend = tdb
        idmap config * : range = 2000-9999

I does not work with : 
        ## map ids from the domain and (*) the range may not overlap !
        idmap config NTDOM : backend = ad
        idmap config NTDOM : schema_mode = rfc2307
        idmap config NTDOM : range = 10000-3999999
Comment 12 Mathieu Parent 2017-01-01 17:11:10 UTC
I fail to understand why the config is wrong.

Also, can you tell me if https://bugs.debian.org/848935 is the same problem?

A patch to add an explicit error message would help.
Comment 13 Rowland Penny 2021-01-09 16:24:38 UTC
This was never a bug,it was caused by trying to configure a Samba AD DC in the same way as a Unix domain member, this will never work.
If there is a bug, it is that a Samba DC will start with the 'idmap config' lines in its smb.conf

If nobody complains, I will close this bug report in seven days.
Comment 14 Rowland Penny 2021-01-17 10:50:42 UTC
Nobody seems to have complained, so closing.