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:
adu...@ad.nwra.com member of aduser_exter...@nwra.com which belongs to
aduser_h...@nwra.com. gid of 108501
id adu...@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_h...@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_h...@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
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
