UPN group name@domain in id output

[Alfred Victor]

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 format. Can anyone please advise what causes this
(backend setting, setup command?)

[test@testingipa ~]# id tester

uid=3993(tester(a)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 \

Roger

[Rob Crittenden]

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:[e-mail]>
>  format. Can anyone please advise what causes this (backend setting,
>  setup command?)
>  
>  [test@testingipa ~]# id tester
>  
>  uid=3993(tester(a)testing.com <mailto:[e-mail]>)
>  
>  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

[Alfred Victor]

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(a)redhat.com&gt; 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:[e-mail]>
>  > format. Can anyone please advise what causes this (backend setting,
>  > setup command?)
>  >
>  > [test@testingipa ~]# id tester
>  >
>  > uid=3993(tester(a)testing.com <mailto:[e-mail]>)
>  >
>  > 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
>
>

[Florence Blanc-Renaud]

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 (a)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/...

>  On Mon, Mar 22, 2021 at 2:48 PM Rob Crittenden
> <rcritten(a)redhat.com 
>  <mailto:[e-mail]>> 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:[e-mail]> <mailto:[e-mail]
>      <mailto:[e-mail]>>
>       > format. Can anyone please advise what causes this (backend setting,
>       > setup command?)
>       >
>       > [test@testingipa ~]# id tester
>       >
>       > uid=3993(tester(a)testing.com <mailto:[e-mail]>
>      <mailto:[e-mail] <mailto:[e-mail]>>)
>       >
>       > 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
>  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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Alfred Victor]

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&gt;
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/...
>
>  > On Mon, Mar 22, 2021 at 2:48 PM Rob Crittenden <rcritten(a)redhat.com
>  > <mailto:[e-mail]>> 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:[e-mail]> <mailto:[e-mail]
>  >     <mailto:[e-mail]>>
>  >      > format. Can anyone please advise what causes this (backend
>  setting,
>  >      > setup command?)
>  >      >
>  >      > [test@testingipa ~]# id tester
>  >      >
>  >      > uid=3993(tester(a)testing.com <mailto:[e-mail]>
>  >     <mailto:[e-mail] <mailto:[e-mail]>>)
>  >      >
>  >      > 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
>  > 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/[e-mail]...
>  > Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  >
>
>

[Alfred Victor]

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(a)gmail.com&gt; 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&gt;
>  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/...
> >
> > > On Mon, Mar 22, 2021 at 2:48 PM Rob Crittenden <rcritten(a)redhat.com
> > > <mailto:[e-mail]>> 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:[e-mail]> <mailto:[e-mail]
> > >     <mailto:[e-mail]>>
> > >      > format. Can anyone please advise what causes this (backend
> > setting,
> > >      > setup command?)
> > >      >
> > >      > [test@testingipa ~]# id tester
> > >      >
> > >      > uid=3993(tester(a)testing.com <mailto:[e-mail]>
> > >     <mailto:[e-mail] <mailto:[e-mail]>>)
> > >      >
> > >      > 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
> > > 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/[e-mail]...
> > > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> > >
> >
> >

[Florence Blanc-Renaud]

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:[e-mail]>> 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:[e-mail]>> 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 (a)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:[e-mail]>
>           > <mailto:[e-mail] <mailto:[e-mail]>>>
> 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:[e-mail]>
>           >     <mailto:[e-mail] <mailto:[e-mail]>>
>          <mailto:[e-mail] <mailto:[e-mail]>
>           >     <mailto:[e-mail]
> <mailto:[e-mail]>>>
>           >      > format. Can anyone please advise what causes this
>          (backend setting,
>           >      > setup command?)
>           >      >
>           >      > [test@testingipa ~]# id tester
>           >      >
>           >      > uid=3993(tester(a)testing.com
>          <mailto:[e-mail]> <mailto:[e-mail]
>          <mailto:[e-mail]>>
>           >     <mailto:[e-mail] <mailto:[e-mail]>
>          <mailto:[e-mail] <mailto:[e-mail]>>>)
>           >      >
>           >      > 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:[e-mail]>
>           > To unsubscribe send an email to
>          freeipa-users-leave(a)lists.fedorahosted.org
>          <mailto:[e-mail]>
>           > 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/[e-mail]...
>         
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>           > 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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Alfred Victor]

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(a)redhat.com&gt;
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(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:[e-mail]>> 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:[e-mail]>> 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:[e-mail]>
>  >          > <mailto:[e-mail]
> <mailto:[e-mail]>>>
>  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:[e-mail]>
>  >          >     <mailto:[e-mail]
> <mailto:[e-mail]>>
>  >         <mailto:[e-mail] <mailto:[e-mail]>
>  >          >     <mailto:[e-mail] <mailto:[e-mail]
>  >>>
>  >          >      > format. Can anyone please advise what causes this
>  >         (backend setting,
>  >          >      > setup command?)
>  >          >      >
>  >          >      > [test@testingipa ~]# id tester
>  >          >      >
>  >          >      > uid=3993(tester(a)testing.com
>  >         <mailto:[e-mail]> <mailto:[e-mail]
>  >         <mailto:[e-mail]>>
>  >          >     <mailto:[e-mail] <mailto:[e-mail]>
>  >         <mailto:[e-mail] <mailto:[e-mail]>>>)
>  >          >      >
>  >          >      > 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:[e-mail]>
>  >          > To unsubscribe send an email to
>  >         freeipa-users-leave(a)lists.fedorahosted.org
>  >         <mailto:[e-mail]>
>  >          > 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/[e-mail]...
>  >         <
>  https://lists.fedorahosted.org/archives/list/[e-mail]...
>  >
>  >          > 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/[e-mail]...
>  > Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  >
>
>

[Florence Blanc-Renaud]

On 3/24/21 5:18 PM, Alfred Victor via FreeIPA-users wrote:
>  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
>   
Thanks for confirming the change was the result of a human intervention. 
Feel free to open a documentation bug with your suggestion for 
improvements, as the warning is currently only visible in sssd.conf man 
page and may not be explicit enough regarding the consequences:

Please, note that when this option is set the output format of all
commands is always fully-qualified even when using short names for
input, for all users but the ones managed by the files provider

flo

>  On Wed, Mar 24, 2021 at 2:06 AM Florence Blanc-Renaud
> <flo(a)redhat.com 
>  <mailto:[e-mail]>> 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(a)DOMAIN.COM <mailto:[e-mail]>:
>      config_mod/1(ipadomainresolutionorder='domain.com
>      <http://domain.com>';, version='2.240'):
>      SUCCESS
>      ----- >8 ------
>      You can identify that admin(a)DOMAIN.COM <mailto:[e-mail]> 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 <http://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:[e-mail]>
>       > <mailto:[e-mail] <mailto:[e-mail]>>> 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>
>      <http://domain.com <http://domain.com>>
>       >
>       >
>       >
>       >     *
>       >
>       >     *
>       >     *
>       >
>       >     *
>       >     *
>       >
>       >
>       >     On Tue, Mar 23, 2021 at 2:22 AM Florence Blanc-Renaud
>       >     &lt;flo(a)redhat.com <mailto:[e-mail]>
>      <mailto:[e-mail] <mailto:[e-mail]>>> 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 (a)domain.com
>      <http://domain.com>
>       >         <http://domain.com <http://domain.com>>
>      <http://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/...
>       >       
>      
>  <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/...
>       >
>       >          > On Mon, Mar 22, 2021 at 2:48 PM Rob Crittenden
>       >         &lt;rcritten(a)redhat.com <mailto:[e-mail]>
>      <mailto:[e-mail] <mailto:[e-mail]>>
>       >          > <mailto:[e-mail]
>      <mailto:[e-mail]> <mailto:[e-mail]
>      <mailto:[e-mail]>>>> 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:[e-mail]>
>       >         <mailto:[e-mail] <mailto:[e-mail]>>
>       >          >     <mailto:[e-mail]
>      <mailto:[e-mail]> <mailto:[e-mail]
>      <mailto:[e-mail]>>>
>       >         <mailto:[e-mail] <mailto:[e-mail]>
>      <mailto:[e-mail] <mailto:[e-mail]>>
>       >          >     <mailto:[e-mail]
>      <mailto:[e-mail]> <mailto:[e-mail]
>      <mailto:[e-mail]>>>>
>       >          >      > format. Can anyone please advise what causes this
>       >         (backend setting,
>       >          >      > setup command?)
>       >          >      >
>       >          >      > [test@testingipa ~]# id tester
>       >          >      >
>       >          >      > uid=3993(tester(a)testing.com
>      <mailto:[e-mail]>
>       >         <mailto:[e-mail] <mailto:[e-mail]>>
>      <mailto:[e-mail] <mailto:[e-mail]>
>       >         <mailto:[e-mail]
> <mailto:[e-mail]>>>
>       >          >     <mailto:[e-mail]
>      <mailto:[e-mail]> <mailto:[e-mail]
>      <mailto:[e-mail]>>
>       >         <mailto:[e-mail] <mailto:[e-mail]>
>      <mailto:[e-mail] <mailto:[e-mail]>>>>)
>       >          >      >
>       >          >      > 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:[e-mail]>
>       >         <mailto:[e-mail]
>      <mailto:[e-mail]>>
>       >          > To unsubscribe send an email to
>       > freeipa-users-leave(a)lists.fedorahosted.org
>      <mailto:[e-mail]>
>       >         <mailto:[e-mail]
>      <mailto:[e-mail]>>
>       >          > Fedora Code of Conduct:
>       > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>      <https://docs.fedoraproject.org/en-US/project/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>
>       >         <https://fedoraproject.org/wiki/Mailing_list_guidelines
>      <https://fedoraproject.org/wiki/Mailing_list_guidelines>>
>       >          > List Archives:
>       >
>      https://lists.fedorahosted.org/archives/list/[e-mail]...
>     
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>       >       
>      
>  <https://lists.fedorahosted.org/archives/list/[e-mail]
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>       >          > Do not reply to spam on the list, report it:
>       > https://pagure.io/fedora-infrastructure
>      <https://pagure.io/fedora-infrastructure>
>       >         <https://pagure.io/fedora-infrastructure
>      <https://pagure.io/fedora-infrastructure>>
>       >          >
>       >
>       >
>       > _______________________________________________
>       > FreeIPA-users mailing list --
>      freeipa-users(a)lists.fedorahosted.org
>      <mailto:[e-mail]>
>       > To unsubscribe send an email to
>      freeipa-users-leave(a)lists.fedorahosted.org
>      <mailto:[e-mail]>
>       > 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/[e-mail]...
>     
> <https://lists.fedorahosted.org/archives/list/[e-mail]...
>       > 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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Anthony Joseph Messina]

On Monday, March 22, 2021 12:32:37 PM CDT 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 format. Can anyone please advise what causes this
>  (backend setting, setup command?)
>  
>  [test@testingipa ~]# id tester
>  
>  uid=3993(tester(a)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 \
>  
>  Roger 
Any chance your sssd.conf has use_fully_qualified_names set?  I used this 
option a while back when testing out libnfsidmap:

https://github.com/SSSD/sssd/issues/4561

-- 
Anthony - https://messinet.com
F9B6 560E 68EA 037D 8C3D  D1C9 FF31 3BDB D9D8 99B6