On 4/30/19 2:51 PM, Alexander Bokovoy wrote:
> On ti, 30 huhti 2019, Orion Poplawski wrote:
>> On 4/30/19 2:14 PM, Rob Crittenden wrote:
>>> Orion Poplawski via FreeIPA-users wrote:
>>>> On 4/30/19 2:00 PM, Alexander Bokovoy wrote:
>>>>> On ti, 30 huhti 2019, Orion Poplawski via FreeIPA-users wrote:
>>>>>> We're seeing some strange gid assignment behavior. When I
run ipa
>>>>>> group-add
>>>>>> on one ipa client I get gids in the expected range for my domain
>>>>>> (8000-10000).
>>>>>> But when it is run on one of our IPA servers we get numbers like
108500 or
>>>>>> 58500.
>>>>>>
>>>>>> ipa idrange-find reports what I would expect everywhere:
>>>>>>
>>>>>> # ipa idrange-find
>>>>>> ----------------
>>>>>> 3 ranges matched
>>>>>> ----------------
>>>>>> Range name: AD.NWRA.COM_id_range
>>>>>> First Posix ID of the range: 20000
>>>>>> Number of IDs in the range: 20000
>>>>>> First RID of the corresponding RID range: 0
>>>>>> Domain SID of the trusted domain: S-1-5-21-XXXX
>>>>>> Range type: Active Directory domain range
>>>>>>
>>>>>> Range name: legacy
>>>>>> First Posix ID of the range: 1000
>>>>>> Number of IDs in the range: 100
>>>>>> First RID of the corresponding RID range: 10000
>>>>>> First RID of the secondary RID range: 100010000
>>>>>> Range type: local domain range
>>>>>>
>>>>>> Range name: NWRA.COM_id_range
>>>>>> First Posix ID of the range: 8000
>>>>>> Number of IDs in the range: 2000
>>>>>> First RID of the corresponding RID range: 1000
>>>>>> First RID of the secondary RID range: 100000000
>>>>>> Range type: local domain range
>>>>>> ----------------------------
>>>>>> Number of entries returned 3
>>>>>> ----------------------------
>>>>>>
>>>>>> ipa-client-4.6.4-10.el7.centos.3.x86_64
>>>>>>
>>>>>>
>>>>>> No idea what else to look at.
>>>>> What about
>>>>> ipa-replica-manage dnarange-show
>>>>> ipa-replica-manage dnanextrange-show
>>>>>
>>>>> ?
>>>>>
>>>>> 'ipa idrange-*' commands are mostly for trusted AD
domains' ranges and
>>>>> local ranges there are simply to allow SSSD to protect the space for
IPA
>>>>> users/groups. When DNA plugin in IPA LDAP generates new IDs, it uses
the
>>>>> data you can see with 'ipa-replica-manage dna*' commands.
>>>>
>>>> Ah, thanks. Yeah, that is different:
>>>>
>>>> #1.nwra.com: 8043-58499
>>>> #2.nwra.com: 58501-108499
>>>> #3.nwra.com: 108502-207999
>>>> #4.nwra.com: No range set
>>>> #5.nwra.com: No range set
>>>>
>>>> So I guess I need to read up on that. Interesting that it is different
>>>> everywhere. I'm assuming that it should match the NWRA.COM_id_range
above.
>>>>
>>>> We seem to be seeing issues with group membership for AD trust users in
HBAC
>>>> groups via external group membership not propagating out to clients, and
I
>>>> guessed that the issue might have been the gid range of the group. I
still
>>>> think it is an issue.
>>>
>>> The IPA domain range by default is 200k IIRC and is (should be)
>>> immutable post-install. Did you really set only 2k entries when you
>>> initially installed IPA?
>>
>> Yes - this was a *LONG* time ago.
>>
>>> Note that 207999 - 8000 = 199999 (not inclusive), so this actually looks ok.
>>>
>>> It also isn't a major problem that masters 4 and 5 don't have a
range,
>>> is just means that users and groups haven't been added there for them to
>>> require a range. It would only make a difference if masters 1-3 died
>>> sudden deaths.
>>
>> Okay - I think I follow this logic better.
>>
>> But I'm still seeing problems with group membership. I have:
>>
>> aduser(a)ad.nwra.com member of aduser_external(a)nwra.com which belongs to
>> aduser_hbac(a)nwra.com. gid of 108501
>>
>> id aduser(a)ad.nwra.com on the IPA servers correctly reports membership in
>> aduser_hbac.
>>
>> but id aduser on the IPA clients do not. We are also making use of:
>>
>> full_name_format = %1$s
>> default_domain_suffix =
ad.nwra.com
>>
>>
>> An error I see on the client:
>>
>> (Tue Apr 30 14:23:26 2019) [sssd[be[nwra.com]]] [ipa_s2n_get_list_next]
>> (0x0400): Received [aduser_hbac(a)nwra.com] attributes from IPA server.
>> (Tue Apr 30 14:23:26 2019) [sssd[be[nwra.com]]] [ipa_s2n_get_list_next]
>> (0x0020): Object [aduser_hbac(a)nwra.com] has no SID, please check the
>> ipaNTSecurityIdentifier attribute on the server-side
>> (Tue Apr 30 14:23:26 2019) [sssd[be[nwra.com]]] [ipa_s2n_get_list_done]
>> (0x0040): s2n get_fqlist request failed.
>>
>> And indeed no ipaNTSecurityIdentifier attribute was created for that group.
>> Probably because again I have a very restrictive range for that and the
>> assigned GID did not fit.
> It is not a GID but rather RID (relative identifier) which is identified
> by available ID ranges for the local range (now that is where 'ipa
> idrange-*' is playing a role). Most likely you had not enough range
> space to allocate one on a server where that group was created.
>
> Read this thread from 2017:
>
https://www.redhat.com/archives/freeipa-users/2017-February/msg00114.html
>
Thanks. I added a new range and made sure that the dnaranges for the various
servers fell within it. I'm assuming (hoping!) that IPA/389 still checks for
duplicate IDs within the DNA range? I have a couple random IDs assigned
within those ranges.