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
Thank you for clearing that up. I did set uid/gid using the NIS tab, and "Domain Users" DOES have a gid. Every group and stock user has an ID. None are the same. With that said, how can I get more information on this invalid SID? I need this up ASAP and my digging has thus far proved fruitless. If I knew which SID(s) were in question and how to check or fix them, I'd happily do it. All I know of however, is idmap.ldb, which doesn't show me anything useful. 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 >
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
>
On Thu, 27 Oct 2016 16:57:30 -0400 Ryan Ashley via samba <samba at lists.samba.org> wrote:> 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.That is Authenticated Users, have you given any of the BUILTIN users and groups a uid/gidNumber ? If so, try removing them. I normally just give 'Domain Users' & 'Domain Admins' a gidNumber. Rowland
Yes,
You'll see that message to some (or all) of the well known sids
https://support.microsoft.com/en-us/kb/243330 . On my logs, the first to show up
is the
Everyone sid (S-1-1-0) . You also might find (on member server logs) references
to the
135 port of the DC, usually, connection refused messages. Going back to 4.4.4
seem to
prevent it. I'm hoping to test Arthur's patch against 4.5.1, as well.
Vinicius.
Em 27/10/2016 18:57, Ryan Ashley via samba escreveu:> 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
>>
--
Vinicius Silva
SOC
BRA: + 55 51 2117.1000 | 55 11 5521.2021
USA: + 1 888 259.5801
vbs at e-trust.com.br
skype: vinicius.bones.silva
Smiley face
www.e-trust.com.br <http://www.e-trust.com.br/>
Esta mensagem pode conter informações confidenciais ou privilegiadas. Se você
recebeu esta
mensagem por engano, você não deve usar, copiar, divulgar ou tomar qualquer
atitude com
base nestas informações. Solicitamos que você apague a mensagem imediatamente e
avise a
E-TRUST, enviando um e-mail para suporte at e-trust.com.br. Opiniões, conclusões
ou
informações contidas nesta mensagem não necessariamente refletem a posição
oficial da
E-TRUST. Caso assinada digitalmente, a autenticidade desta mensagem pode ser
confirmada
pela Autoridade Certificadora Privada E-TRUST, disponível em www.e-trust.com.br.
This message may contain privileged and confidential information for the use of
the
intended recipients only. If you are not an intended recipient then you should
not
disseminate, copy, or take any action based on its contents. If you have
received this
message in error then please notify E-TRUST by sending an e-mail message to
suporte at e-trust.com.br immediately. Views and opinions expressed in this
message do not
necessarily reflect the position of E-TRUST. If this message is digitally
signed, its
authenticity can be confirmed by E-TRUST Private Certificate Authority,
available at
www.e-trust.com.br.
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] > ../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 >> >
On Thu, 2016-10-27 at 16:57 -0400, 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] > ../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?Do you have more logs? I see you have had a long discussion here, but without looking into the debug logs it really is unlikely we will understand what is actually going on. A bug has been filed for what is superficially your issue: https://bugzilla.samba.org/show_bug.cgi?id=12393 But again, only level 0 logs were attached, and we need more. (Probably not level 100, at least on on public bugzilla, but 2 or 4 would be nice). However, I think you have a different issue under the same error code. Looking over the recent winbindd changes, I would revert these patches: https://attachments.samba.org/attachment.cgi?id=12373 As the AD DC does not honour IDMAP ranges, the 'central check' may well fail. It is worth a shot in any case. I'm sorry this has been so frustrating. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba