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, 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

On Mon, Mar 22, 2021 at 2:48 PM Rob Crittenden <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>
> 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>)
>
> 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