Hi FreeIPA,

We have found the cause was a GUI change. I have spoken with my colleague, who at first did not recall any change, but after looking and given the log did realize. It seems like this function may be poorly described in the GUI, as it appears to affect shortnames or something more innocent than effectively changing the entire linux user/group system (for instance, matches in sshd_config no longer work).

Thanks
Roger

On Wed, Mar 24, 2021 at 2:06 AM Florence Blanc-Renaud <flo@redhat.com> wrote:
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@DOMAIN.COM:
config_mod/1(ipadomainresolutionorder='domain.com', version='2.240'):
SUCCESS
----- >8 ------
You can identify that admin@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@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@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/html-single/windows_integration_guide/index#short-names
>         <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/windows_integration_guide/index#short-names>
>
>          > On Mon, Mar 22, 2021 at 2:48 PM Rob Crittenden
>         <rcritten@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@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@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@lists.fedorahosted.org
>         <mailto:freeipa-users@lists.fedorahosted.org>
>          > To unsubscribe send an email to
>         freeipa-users-leave@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.fedorahosted.org
>         <https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org>
>          > 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@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@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.fedorahosted.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>