[Samba] NT_STATUS_INVALID_SID

Thu Oct 27 20:57:30 UTC 2016

I just found this in a log. It is the smbd log, to be exact.

[2016/10/27 16:54:11.689360,  0]
../source4/auth/unix_token.c:107(security_token_to_unix_token)
  Unable to convert SID (S-1-5-11) at index 9 in user token to a GID.
Conversion was returned as type 0, full token:
[2016/10/27 16:54:11.689734,  0]
../libcli/security/security_token.c:63(security_token_debug)
  Security token SIDs (13):
    SID[  0]: S-1-5-21-1106274642-2786564146-798650368-500
    SID[  1]: S-1-5-21-1106274642-2786564146-798650368-513
    SID[  2]: S-1-5-21-1106274642-2786564146-798650368-520
    SID[  3]: S-1-5-21-1106274642-2786564146-798650368-572
    SID[  4]: S-1-5-21-1106274642-2786564146-798650368-519
    SID[  5]: S-1-5-21-1106274642-2786564146-798650368-518
    SID[  6]: S-1-5-21-1106274642-2786564146-798650368-512
    SID[  7]: S-1-1-0
    SID[  8]: S-1-5-2
    SID[  9]: S-1-5-11
    SID[ 10]: S-1-5-32-544
    SID[ 11]: S-1-5-32-545
    SID[ 12]: S-1-5-32-554
   Privileges (0x        1FFFFF00):
    Privilege[  0]: SeTakeOwnershipPrivilege
    Privilege[  1]: SeBackupPrivilege
    Privilege[  2]: SeRestorePrivilege
    Privilege[  3]: SeRemoteShutdownPrivilege
    Privilege[  4]: SeSecurityPrivilege
    Privilege[  5]: SeSystemtimePrivilege
    Privilege[  6]: SeShutdownPrivilege
    Privilege[  7]: SeDebugPrivilege
    Privilege[  8]: SeSystemEnvironmentPrivilege
    Privilege[  9]: SeSystemProfilePrivilege
    Privilege[ 10]: SeProfileSingleProcessPrivilege
    Privilege[ 11]: SeIncreaseBasePriorityPrivilege
    Privilege[ 12]: SeLoadDriverPrivilege
    Privilege[ 13]: SeCreatePagefilePrivilege
    Privilege[ 14]: SeIncreaseQuotaPrivilege
    Privilege[ 15]: SeChangeNotifyPrivilege
    Privilege[ 16]: SeUndockPrivilege
    Privilege[ 17]: SeManageVolumePrivilege
    Privilege[ 18]: SeImpersonatePrivilege
    Privilege[ 19]: SeCreateGlobalPrivilege
    Privilege[ 20]: SeEnableDelegationPrivilege
   Rights (0x             403):
    Right[  0]: SeInteractiveLogonRight
    Right[  1]: SeNetworkLogonRight
    Right[  2]: SeRemoteInteractiveLogonRight

Isn't this the builtin group?

Lead IT/IS Specialist
Reach Technology FP, Inc

On 10/27/2016 04:21 PM, Rowland Penny via samba wrote:
> On Thu, 27 Oct 2016 15:52:09 -0400
> Ryan Ashley via samba <samba at lists.samba.org> wrote:
> 
>> Slightly off-topic, but I thought setting those set the limits for
>> going into the NIS attributes tab in Windows. I understood the Samba
>> wiki to explain that using those lines is how you set the upper and
>> lower limits that Windows sees and uses. Is this incorrect?
>>
>> Lead IT/IS Specialist
>> Reach Technology FP, Inc
>>
>> On 10/27/2016 03:42 PM, Rowland Penny via samba wrote:
>>> On Thu, 27 Oct 2016 17:23:43 -0200
>>> Vinicius Bones Silva via samba <samba at lists.samba.org> wrote:
>>>
>>>> Hi Rowland,
>>>>
>>>>      Just to let you know, we removed all the idmap entries we had
>>>> on the smb.conf of our two DCs and the ids reported by getent
>>>> passwd at the DCs were in the 3.000.000 range, as you said. We had
>>>> to add back 'idmap_ldb:use rfc2307 = yes' to get the user listing
>>>> with the original numbers on the DCs.
>>>>
>>>> Here's what we commented out on the configurationfiles.
>>>>
>>>>          # Default idmap config used for BUILTIN and local
>>>> accounts/groups #idmap config *:backend = ad
>>>>          #idmap config *:range = 2000-9999
>>>>
>>>>          # idmap config for domain E-TRUST
>>>>          #idmap config E-TRUST:backend = ad
>>>>          #idmap config E-TRUST:schema_mode = rfc2307
>>>>          #idmap config E-TRUST:range = 10000-40000
>>>>          #idmap cache time = 1
>>>>          #idmap negative cache time = 1
>>>>          #winbind cache time = 1
>>>>          idmap_ldb:use rfc2307 = yes
>>>>
>>>
>>> Yes those are the lines you should only have on a domain member (aka
>>> fileserver, printserver). The only idmap line you should have on a
>>> DC is the 'idmap_ldb:use rfc2307 = yes' line, without this line,
>>> rfc2307 will not be used and unfortunately it is not added
>>> automatically to any DCs that are joined to the domain.
>>>
>>> Rowland
>>>  
>>>
>>
> 
> OK, when you first provision Samba as an AD DC, it uses 'xidNumber'
> attributes stored in 'idmap.ldb', these numbers are in the '3000000'
> range. These numbers are allocated on a first come basis (this is why
> you get different IDs on subsequent DCs)
> 
> The only way to get different ID numbers on a DC, use uidNumber &
> gidNumber attributes, but you don't need to add anything to smb.conf.
> 
> On a domain member it is different, there are several 'idmap' winbind
> backends you can use, but the two main ones are 'ad' and 'rid'.
> 
> If you haven't added any uidNumber & gidNumber attributes to AD, then
> you should use the 'rid' backend, this calculates the users (or group)
> ID from its RID (the only real constant in all of this) and as long as
> you use the same range on all Unix domain members, you will get
> the same ID on them.
> 
> If you have added uidNumber & gidNumber attributes to AD, then you
> should use the 'ad' backend, again, if you use the same range on all
> the domain members, you will get the same ID's everywhere including
> the DC's.
> 
> The ranges (whether you use 'rid' or 'ad') must not overlap and if
> you use 'ad', you must give 'Domain Users' a gidNumber.
> 
> If you use the 'rid' backend, the ID's will be set from the range you
> set in smb.conf, whereas, if you use the 'ad' backend, you set the
> range from the numbers you set in AD.
> 
> Rowland  
> 