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?
Roger
On Tue, Mar 23, 2021 at 11:22 AM Alfred Victor 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 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, 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/htm...
On Mon, Mar 22, 2021 at 2:48 PM Rob Crittenden <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>> > 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>>) > > 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 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.fedorahoste...
Do not reply to spam on the list, report it: