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] ad...@domain.com:
config_mod/1(ipadomainresolutionorder='domain.com', version='2.240'):
SUCCESS
----- >8 ------
You can identify that ad...@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 <alvic...@gmail.com
<mailto:alvic...@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
<f...@redhat.com <mailto:f...@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
<rcrit...@redhat.com <mailto:rcrit...@redhat.com>
> <mailto:rcrit...@redhat.com <mailto:rcrit...@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 usern...@domain.com
<mailto:usern...@domain.com>
> <mailto:usern...@domain.com <mailto:usern...@domain.com>>
<mailto:usern...@domain.com <mailto:usern...@domain.com>
> <mailto:usern...@domain.com <mailto:usern...@domain.com>>>
> > format. Can anyone please advise what causes this
(backend setting,
> > setup command?)
> >
> > [test@testingipa ~]# id tester
> >
> > uid=3993(tes...@testing.com
<mailto:tes...@testing.com> <mailto:tes...@testing.com
<mailto:tes...@testing.com>>
> <mailto:tes...@testing.com <mailto:tes...@testing.com>
<mailto:tes...@testing.com <mailto:tes...@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-le...@lists.fedorahosted.org
<mailto:freeipa-users-le...@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-le...@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
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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
