ryana at reachtechfp.com
Thu Oct 27 21:16:59 UTC 2016
More information, now that I have the SID in question.
root at dc01:~# wbinfo --sid-to-gid S-1-5-11
failed to call wbcSidToGid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-11 to gid
root at dc01:~# wbinfo --sid-to-uid S-1-5-11
failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-11 to uid
root at dc01:~# wbinfo --sid-to-name S-1-5-11
failed to call wbcLookupSid: WBC_ERR_DOMAIN_NOT_FOUND
Could not lookup sid S-1-5-11
root at dc01:~# wbinfo --sid-to-fullname S-1-5-11
failed to call wbcGetDisplayName: WBC_ERR_DOMAIN_NOT_FOUND
Could not lookup sid S-1-5-11
This works for other SIDs, just not S-1-5-11.
Lead IT/IS Specialist
Reach Technology FP, Inc
On 10/27/2016 04:57 PM, Ryan Ashley via samba wrote:
> I just found this in a log. It is the smbd log, to be exact.
> [2016/10/27 16:54:11.689360, 0]
> 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]
> 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.
>> 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.
More information about the samba