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 <[email protected]
<mailto:[email protected]>> 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] [email protected] <mailto:[email protected]>:
config_mod/1(ipadomainresolutionorder='domain.com
<http://domain.com>', version='2.240'):
SUCCESS
----- >8 ------
You can identify that [email protected] <mailto:[email protected]> 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
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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>>
<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/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>
>
<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
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>> 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 [email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>
> > > format. Can anyone please advise what causes this
> (backend setting,
> > > setup command?)
> > >
> > > [test@testingipa ~]# id tester
> > >
> > > uid=3993([email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>)
> > >
> > > 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 --
> [email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > To unsubscribe send an email to
> [email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> > 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/[email protected]
<https://lists.fedorahosted.org/archives/list/[email protected]>
>
<https://lists.fedorahosted.org/archives/list/[email protected] <https://lists.fedorahosted.org/archives/list/[email protected]>>
> > 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 --
[email protected]
<mailto:[email protected]>
> To unsubscribe send an email to
[email protected]
<mailto:[email protected]>
> 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/[email protected]
<https://lists.fedorahosted.org/archives/list/[email protected]>
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
<https://pagure.io/fedora-infrastructure>
>
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
