Am Tue, Jun 29, 2021 at 02:11:15PM -0000 schrieb iulian roman via FreeIPA-users: > Hello everybody, > > I try to make the above combination to work in my environment , and > already spent several weeks + open a few threads with different sort > of issues. So far, I can say that it works only with workarounds , > restarts, clear caches, etc , which is not the setup I can move in > production with. > > I try to provide the latest update of the setup and the issues I am > currently facing: > > RedHat Idm with AD trust configured (non-posix) > Default Trust View configured which overrides the UID and GID of the > AD users The UID and GID do exist in Active Directory (the user and > group have the same name) , although the group name is in different OU > - I do not know if this is an issue or not
Hi, did you, by chance, use the 'ldap_group_name' option to override the attribute for the group name? I'm aksing because by default the attribute 'sAMAccountName' is used for user and group names and the attribute has a unique-constraint in AD, i.e. there cannot be a user and a group with the same 'sAMAccountName'. The reason for this constraint is to be able to have a 1:1 relationship between the names and the SIDs. If you have modified sssd.conf on the IPA servers in this or a similar way this might be the reason for the inconsistent behavior you are seeing. bye, Sumit > > On the client, some of the users are resolved, some not. If I manually > run getent group <username> before running the id command, it does > resolve the group and user. Without running getent group command, > sometimes it resolves, sometimes not. > > I checked the logs on the client and server and the errors I noticed > when running id <username> are: > > on the client: > [ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: No such > object(32), (null) > > on the server: > [nss] [nss_protocol_fill_initgr] (0x0080): Unable to find primary gid [2]: No > such file or directory > > It seems to be related to the magical primary GID which seems to be > the source of all my issues, but I. have no idea how to fix it (the > GID exist in AD and it is defined in the Default Trust View). I am > considering even changing settings in AD, but I do not know what > should I change. > > I tried to define as well all the AD groups (for which I do group > override in Default Trust View) in IPA as posix groups with that > specific GID . In that situation for some users the lookup failed > first time but after the negative cache expired or sssd is restarted > the lookup for the user and group works properly (situation was quite > similar with the one in the thread > https://lists.fedorahosted.org/archives/list/[email protected]/thread/VHTB3GR65L77SS7CS5H4GWHRMBIKQWXP/ > ). > > For AD users which do not have attributes overwritten everything works > properly. > _______________________________________________ > FreeIPA-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
