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.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301