[Freeipa-users] Re: UPN group name@domain in id output

On 3/23/21 7:57 PM, Alfred Victor via FreeIPA-users wrote: > I should clarify that I have now asked all involved and no one > recognizes this change, so is it fair to assume adding a replica has > somehow imparted this, or should we dig through logs? > Hi, I didn't find any place in the code where this setting would be changed automatically. If you want to check the logs, there are 2 ways this could have been modified: - with ipa config-mod --domain-resolution-order / the GUI In this case, the operation can be seen in /var/log/httpd/error_log: ----- 8< ----- [Wed Mar 24 07:51:35.606541 2021] [wsgi:error] [pid 74556:tid 74882] [remote 2620:52:0:25aa:a0d5:3d18:27b6:fe2f:33008] ipa: INFO: [jsonserver_session] admin(a)DOMAIN.COM: config_mod/1(ipadomainresolutionorder='domain.com', version='2.240'): SUCCESS ----- >8 ------ You can identify that admin(a)DOMAIN.COM did the change. - directly in LDAP with a ldapmodify operation If you have audit log enabled, the operation can be seen in /var/log/dirsrv/slapd-DOMAIN-COM/audit and shows the id of the modifier: ----- 8< ----- time: 20210324075135 dn: cn=ipaConfig,cn=etc,dc=domain,dc=com result: 0 changetype: modify replace: ipaDomainResolutionOrder ipaDomainResolutionOrder: domain.com - replace: modifiersname modifiersname: uid=admin,cn=users,cn=accounts,dc=domain,dc=com - replace: modifytimestamp modifytimestamp: 20210324065135Z - replace: entryusn entryusn: 1731 ----- >8 ----- If you don't have audit log enabled, the access log in /var/log/dirsrv/slapd-DOMAIN-COM/access shows that a MOD happened on the entry but any attribute could have been modified: ----- 8< ----- [24/Mar/2021:07:51:35.410659905 +0100] conn=11814 op=5 MOD dn="cn=ipaConfig,cn=etc,dc=domain,dc=com" [24/Mar/2021:07:51:35.498881450 +0100] conn=11814 op=5 RESULT err=0 tag=103 nentries=0 wtime=0.000233131 optime=0.088229999 etime=0.088459773 ----- >8 ----- In order to find who perform the operation, note the conn=xxxxx ID and look for a BIND using the same conn=xxxxx in the previous lines. The result of the BIND operation (same op=yyyy) logs the authenticated DN: ----- 8< ----- [24/Mar/2021:07:51:35.360647328 +0100] conn=11814 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO [24/Mar/2021:07:51:35.378762597 +0100] conn=11814 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000379835 optime=0.018139003 etime=0.018516680 dn="uid=admin,cn=users,cn=accounts,dc=domain,dc=com" ----- >8 ----- HTH, flo > Roger > > On Tue, Mar 23, 2021 at 11:22 AM Alfred Victor <alvic266(a)gmail.com > <mailto:alvic266@gmail.com>> wrote: > > Hi, I do see this set, but I'm not sure when or how this happened. > Can we simply revert this and reboot the hosts and functionally > shouldn't be different than before this got set somehow, other than > no longer showing fqdn? The only recent change I am aware of is > setting up some recent new replicas. Could this somehow be related? > Roger > > *Domain resolution order: domain.com <http://domain.com> > > > > * > > * > * > > * > * > > > On Tue, Mar 23, 2021 at 2:22 AM Florence Blanc-Renaud > <flo(a)redhat.com <mailto:flo@redhat.com>> wrote: > > On 3/22/21 9:26 PM, Alfred Victor via FreeIPA-users wrote: > > Hi Rob, > > > > This is on a newly re-enrolled client (it runs force-join, > previously it > > joined with different arguments but the machine does not > have any data > > that itself persists between boots). I don't see the issue on a > > previously enrolled client. I have verified this is causing > the failure > > with group related auth because if I edit the group names in > > /etc/ssh/sshd_config to include @domain.com > <http://domain.com> <http://domain.com <http://domain.com>>;, I am > > able to log on as my user via key. I am also concerned that > this can > > affect other processes and systems, as I'm not sure what has > caused it > > and it persists after each ipa setup (reboot of the machine). > I did > > notice the following enabled in IPA server->configuration: > > > > MS-PAC > > > > But I'm not sure if this has anything to do with the behavior. > > > > Roger > > > Hi, > > there are multiple settings that can affect the use of fully > qualified > names [1]. At IPA level, is the domain resolution order set? > # ipa config-show | grep 'Domain resolution order' > > The domain_resolution_order setting also exists in sssd.conf and is > affected by full_name_format. More details available in > sssd.conf(5) man > page, but in short, if a domain resolution order is set, the > output of > the id command will display fully qualified names. > > HTH, > flo > > [1] > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/... > < https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/... > > > > On Mon, Mar 22, 2021 at 2:48 PM Rob Crittenden > <rcritten(a)redhat.com <mailto:rcritten@redhat.com> > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>> wrote: > > > > Alfred Victor via FreeIPA-users wrote: > > > Hi FreeIPA, > > > > > > It seems like something has changed but I can't figure > out quite what > > > and a colleague is out sick. When I perform id lookup > on a user, > > > everything shows as username(a)domain.com > <mailto:username@domain.com> > > <mailto:username@domain.com <mailto:username@domain.com>> > <mailto:username@domain.com <mailto:username@domain.com> > > <mailto:username@domain.com <mailto:username@domain.com >>> > > > format. Can anyone please advise what causes this > (backend setting, > > > setup command?) > > > > > > [test@testingipa ~]# id tester > > > > > > uid=3993(tester(a)testing.com > <mailto:tester@testing.com> <mailto:tester@testing.com > <mailto:tester@testing.com>> > > <mailto:tester@testing.com <mailto:tester@testing.com> > <mailto:tester@testing.com <mailto:tester@testing.com>>>) > > > > > > I believe anecdotally this is causing some group based > auth to fail. > > > Here's setup command args: > > > > > > --enable-dns-updates \ > > > > > > --ssh-trust-dns \ > > > > We need more context. This is universal across all > clients/servers? On a > > previously enrolled client? A newly enrolled client? > > > > rob > > > > > > _______________________________________________ > > FreeIPA-users mailing list -- > freeipa-users(a)lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > To unsubscribe send an email to > freeipa-users-leave(a)lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > <https://fedoraproject.org/wiki/Mailing_list_guidelines> > > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... > < https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... > > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > <https://pagure.io/fedora-infrastructure> > > > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > 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/freeipa-users@lists.fedoraho... > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure >