Authentication fails after upgrading sssd to 2.2.3-3ubuntu0.6

[r0mulux]

[ Impact ]

A user running a Samba Active Directory Domain Controller compliant with the MS ADTS specifications in regards to how GPO is handled will experience authentication failures when joining an AD realm using the Ubuntu sssd package on Focal, Impish and Jammy with the "fix-gpo-MS-ADTS-compliance.patch" patch applied. Although there is a relatively simple workaround (setting "ad_gpo_access_control = permissive" in /etc/sssd/sssd.conf), we can and should support regular user authentication out of the box.

Upstream sssd has fixed this problem on version 2.7.0, which will be available in Kinetic soon.

[ Test Plan ]

The test case for this bug is a bit complex, but I will do my best to describe it in detail.

We need to setup one VM running a Samba Active Directory Domain Controller (AD DC), which will be our main server. This needs only to be configured once. We then need to setup another VM which will join our AD DC realm using realmd and sssd.

== Virtual Network setup ==

The first step is to create a dedicated virtual network for our tests. This is not strictly mandatory, but it will simplify things. The best way to create this network is via virt-manager. Install it if needed, open the program and select the "QEMU/KVM" line. Go to Edit > Connection Details > Virtual Networks, click on the "+" icon (bottom left), give this network a name (I will use "sssdad"), make sure that "Enable IPv4" and "Enable DHCPv4" are selected (under "IPv4 configuration"). Go to "DNS domain name" and select "Custom". For the domain name, type "test.lan". Click on "Finish".

Take note of the "Device" name that shows up after you create the network. We will use it when creating the VMs. For this test plan, let's assume the device name is "virbr1".

== Samba AD DC VM setup ==

We need to setup a Samba AD DC server. It doesn't matter which Ubuntu release we use for it. Note that we have to use "-n virbr1" when creating the VM, otherwise it won't use our virtual network.

$ lxc launch ubuntu-daily:jammy sambadc -n virbr1 --vm
$ lxc shell sambadc
server# apt update
server# ip a

Make sure to grab this VM's IP address.

server# cat >> /etc/hosts << _EOF_
IP_ADDRESS_HERE sambadc sambadc.test.lan
_EOF_
server# reboot
$ lxc shell sambadc
server# apt install -y samba winbind

server# mv /etc/samba/smb.conf /etc/samba/smb.conf.bkp
server# samba-tool domain provision --use-rfc2307 --realm TEST.LAN --domain TEST --server-role dc --dns-backend SAMBA_INTERNAL --adminpass MyPassword1

server# systemctl mask smbd.service nmbd.service winbind.service
server# systemctl disable --now smbd.service nmbd.service winbind.service
server# systemctl unmask samba-ad-dc.service
server# systemctl enable --now samba-ad-dc.service

We now have to adjust the DNS server settings of the server. We are going to disable systemd-resolved.service and use samba as our DNS service.

You will notice that the samba-tool command issued above has added 127.0.0.53 as the "dns forwarder" in /etc/samba/smb.conf. Edit the file and set the forwarder to be the virtual network's DNS resolver -- it should be the same as IP_ADDRESS_HERE, but ending in .1.

server# systemctl disable --now systemd-resolved.service
server# unlink /etc/resolv.conf
server# cat > /etc/resolv.conf << _EOF_
nameserver IP_ADDRESS_HERE
search test.lan
_EOF_
server# reboot

This should be enough to configure Samba as an AD DC. While at it, create a test user that will later be used to trigger the bug.

server# samba-tool user create testuser MyUserPassword1

== VM AD client setup ==

Let's configure a VM to act as an AD client.

$ lxc launch ubuntu-daily:jammy sssdclient -n virbr1 --vm
$ lxc shell sssdclient

Before anything else, let's configure this VM to use the Samba AD DC VM as its DNS resolver. In the excerpt below, IP_ADDRESS_HERE refers to the IP address of the Samba AD DC VM (configured in the last section).

client# systemctl disable --now systemd-resolved.service
client# unlink /etc/resolv.conf
client# cat > /etc/resolv.conf << _EOF_
nameserver IP_ADDRESS_HERE
search test.lan
_EOF_

client# apt update
client# apt install -y sssd-ad sssd-tools realmd adcli sssd-dbus
client# pam-auth-update --enable mkhomedir

We can now check if our container can detect the AD DC:

client# realm -v discover sambadc.test.lan
 * Resolving: _ldap._tcp.sambadc.test.lan
 * Resolving: sambadc.test.lan
 * Performing LDAP DSE lookup on: 192.168.101.142
 * Successfully discovered: test.lan
test.lan
  type: kerberos
  realm-name: TEST.LAN
  domain-name: test.lan
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin

You can also confirm that the "realm -v discover" works on the domain name:

client# realm -v discover test.lan
 * Resolving: _ldap._tcp.test.lan
 * Performing LDAP DSE lookup on: 192.168.101.142
 * Successfully discovered: test.lan
test.lan
  type: kerberos
  realm-name: TEST.LAN
  domain-name: test.lan
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin

And we can join the realm:

client# realm -v join test.lan

You will be prompted the password for the Administrator user. It is MyPassword1. If everything worked OK, you should now be able to list the information from the Administrator user:

client# getent passwd <email address hidden>
<email address hidden>:*:1522000500:1522000513:Administrator:/<email address hidden>:/bin/bash

== Reproducing the bug ==

Make sure you can obtain the passwd information for the test user we've created in the Samba AD DC server.

client# getent passwd <email address hidden>
<email address hidden>:*:1522001104:1522000513:testuser:/<email address hidden>:/bin/bash

Now, try to login as the user:

client# login <email address hidden>
Password: MyUserPassword1

System error

As can be seen, the user will get a system error when trying to login in a default AD DC setup. In order to confirm that the problem is indeed caused by GPO, the following line can be added to the end of the /etc/sssd/sssd.conf file:

ad_gpo_access_control = permissive

After restarting sssd.service and trying to login again, you can confirm that it succeeds.

Be aware of the client-side caching when testing sssd. Sometimes the authentication can work when it's not expected to, or vice-versa. It's recommended to completely remove sssd's cache before testing a new scenario:

client# sssctl cache-remove -o -p -s

[ Where problems could occur ]

The behaviour being introduced by this change goes against the specificiation for Group Policies by Microsoft. It is worth mentioning that Microsoft Windows itself does *not* follow the specification either, so in a way we are bringing sssd to the "de facto" standard. But users can be surprised to see the authentication process successfully finish even if there is no SecEdit\GptTmpl.inf available.

As usual, there is also the small risk of rebuilding a package against newer dependencies in the archive.

[ Original Description ]

Hello,

After upgrade of sssd packages from version 2.2.3-3ubuntu0.4 to version 2.2.3-3ubuntu0.6, I could not authenticate with users from my Samba4 directory.

After enabling debug, I can see in /var/log/sssd/gpo_child.log errors:

(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): gpo_child started.
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): context initialized
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x0400): cached_gpt_version: -1
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server length: 21
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_server: smb://MY_SERVER_FQDN
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share length: 7
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_share: /sysvol
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path length: 60
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_path: /MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix length: 49
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [unpack_buffer] (0x4000): smb_cse_suffix: /Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0400): performing smb operations
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://MY_SERVER_FQDN/sysvol/MY_DOMAIN/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [13][Permission denied]
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): perform_smb_operations failed.[13][Permission denied].
(Mon Jul 5 18:15:20 2021) [gpo_child[9895]] [main] (0x0020): gpo_child failed!

(I have replaced real server and domain name by MY_SERVER_FQDN and MY_DOMAIN)

As a workaround, I add new option 'ad_gpo_access_control = permissive' in sssd.conf and authentication is working again, but I'm wondering why upgrade has broken authentication, and what is the impact of the option ?

here is my sssd.conf:

[sssd]
default_domain_suffix = my_domain
full_name_format = %1$s
domains = my_domain
config_file_version = 2
services = nss, pam

[domain/my_domain]
debug_level=9
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MY_DOMAIN
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%d/%u
ad_domain = my_domain
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad

After adding 'ad_gpo_access_control = permissive' at the end of file, authentication with samba4 users works again.

Thanks!

[Jean-Baptiste Lallement (jibel)]

Thank you for your report and sorry for the issue caused by this SRU.

In focal GPO are enforced by default. But the original version of SSSD was not fully implementing the MS spec and GPO where actually not enforced. This was the case for the default domain policy which defines in particular the security and password policy which where not followed.

This is what this SRU addressed by backporting most the GPO fixes from recent version of SSSD and created this unfortunate side effect.

This problem will occur when users will upgrade from 20.04 to 22.04 anyway.

Adding 'ad_gpo_access_control = permissive' to sssd.conf is one way to fix it. Another way is to make sure the default domain policy is properly defined and that the client can access it.

However we will have a look at a Samba4 setup to try to understand if there is a general problem with this setup and how it can be addressed before 22.04 is released.

[EOLE team (eole-team)]

We found issues too and work around it by using 'access_provider = permit' instead of 'access_provider = ad'.

[Damien Clabaut (dclabaut)]

Hello,

I have the same issues on a fleet on Ubuntu 20.04 machines joined to a Univention Corporate Server domain. UCS uses Samba4 as a background.

Is there any security concern about the 'ad_gpo_access_control = permissive' or 'access_provider = permit' in sssd.conf?

Thank you for looking into this issue

[Valtteri Vuorikoski (vuorik)]

I just got hit by this. While 'ad_gpo_access_control = permissive' lets users log in again, it is not ideal.

It appears that Samba AD does not create GptTmpl.inf except for policies which actually set something in "Security Settings". Hence a policy with nothing no security settings will not have the file, which will lead SSSD to get "file not found" when trying to download it and fail PAM auth.

I don't know if Samba is in the wrong here, but anyway treating GptTmpl.inf not found as "no security settings" seems like a reasonable approach.

Anyway, a deb-changelog warning for this kind of change in a minor-minor release would have been most welcome.

[Sergio Durigan Junior (sergiodj)]

OK, after spending a few hours investigating this bug I think I can write a summary of my findings now.

First, thanks everybody who have commented on the bug.

It took me a while to set up a local Samba AD DC with GPO enabled in a VM, and then a container which joins the AD using SSSD (realm + adcli), but I finally have something working here.

I can easily reproduce the problem when I enable GPO on the Samba AD DC and then try to do a regular user login on the client. I can also confirm that Valtteri's analysis seems good indeed: the Samba AD DC doesn't create the GptTmpl.inf file automatically, and SSSD doesn't handle this very well (since https://github.com/SSSD/sssd/issues/4356, apparently). I haven't tested it myself, but I have read reports from users saying that Windows machines don't have problems with this non-existing file.

After investigating a bit more, I found https://bugzilla.redhat.com/show_bug.cgi?id=1839805. This is basically the same bug report as this one, but for Fedora. In there, you can see that one of the developers mentions that SSSD should not be affected by the non-existence of this file, just like Windows isn't. I agree. The only thing I could find in the upstream git repo that addresses this problem is https://github.com/SSSD/sssd/pull/844, which has apparently been abandoned.

Now, I understand that this is a frustrating situation for some users and I agree that we could have mentioned this change in a NEWS file or something more visible. Right now, there are two possible workarounds that I know of here:

1) The easiest one, as said above, is to use the following setting in your /etc/sssd/sssd.conf:

ad_gpo_access_control = permissive

This will make SSSD try to perform GPO operations, but not fail if it can't.

2) The other possible solution, as explained by Sumit Bose on that Fedora bug, is to create the GptTpml.inf file by hand with the following contents:

-------- snip --------
[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
-------- snip --------

which, according to Sumit, represents just an empty policy file with a valid header. I tested this workaround here and it seems to work:

# cd /var/lib/samba/sysvol/test.lan/Policies/\{31B2F340-016D-11D2-945F-00C04FB984F9\}/MACHINE/
# mkdir -p Microsoft/Windows\ NT/SecEdit/
# cd Microsoft/Windows\ NT/SecEdit/
# cat > GptTmpl.inf << EOF
[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
EOF

Then, in the client machine:

# login
sambaclientdc1 login: <email address hidden>
Password:
...
<email address hidden>@sambaclientdc1:~$

I think it is also important to mention that this problem would be introduced anyway if/when you updated to a newer version of Ubuntu, because the recent SSSD versions all have this GPO code in place. As far as I have investigated, it doesn't seem to me that Samba is at fault here.

I will try to talk to the SSSD developers and see if they have any plans to tackle this problem.

[Sergio Durigan Junior (sergiodj)]

Still waiting on upstream.

[Andreas Hasenack (ahasenack)]

https://github.com/SSSD/sssd/pull/6051/files seems to be the new PR to address this, and it's closed. Have to check if it was merged into one of the stable release branches, or even better, if it's part of a release.

[Andreas Hasenack (ahasenack)]

These releases have the fix:

$ git tag --contains 81d67a592315740d13e48b9a29e29baa8cc35638
2.7.0
2.7.1

[Andreas Hasenack (ahasenack)]

I added a task to, in the meantime, update the server guide with the available workarounds for now.

[Andreas Hasenack (ahasenack)]

I also just added an entry to the 22.04 release notes at https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668

[Andreas Hasenack (ahasenack)]

I added a note to the SSSD docs at https://discourse.ubuntu.com/t/sssd-and-active-directory/27888 which will be live in ubuntu.com/server/docs shortly. I almost changed my mind, since the bug will eventually be fixed and then it won't be needed in the docs anymore. I'll remove the note again once this bug is fixed in 22.04.

[Sergio Durigan Junior (sergiodj)]

Another user reported being affected by this bug on #ubuntu-server today. I plan to start working on SRUing this tomorrow.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sergio Durigan Junior (sergiodj)]

Impish will go EOL in less than a month, so I'm marking its task as Won't Fix.

[Launchpad Janitor (janitor)]

This bug was fixed in the package sssd - 2.7.1-2ubuntu1

---------------
sssd (2.7.1-2ubuntu1) kinetic; urgency=medium

  * Merge with Debian unstable (LP: #1971327, #1934997). Remaining changes:
    - d/control: Drop libgdm-dev Build-Depend on i386.
    - d/control: Don't build sssd-tools on i386, now uninstallable due
      to added python3-{click,systemd} dependencies.
  * Dropped changes:
    - d/rules: Disable lto, not ready upstream.
    [ Incorporated by Debian ]

 -- Sergio Durigan Junior <email address hidden> Tue, 14 Jun 2022 16:59:20 -0400

[Steve Langasek (vorlon)]

Hello r0mulux, or anyone else affected,

Accepted sssd into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sssd/2.6.3-1ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Andreas Hasenack (ahasenack)]

Jammy verification

root@j-client-1934997:~# apt-cache policy sssd
sssd:
  Installed: 2.6.3-1ubuntu3
  Candidate: 2.6.3-1ubuntu3
  Version table:
 *** 2.6.3-1ubuntu3 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

With the packages from jammy, the login fails with a system error:

root@j-client-1934997:~# login <email address hidden>
Password:

System error

And I get the error in the logs about the missing gpo file:
  * (2022-07-02 0:21:26): [gpo_child[4606]] [copy_smb_file_to_gpo_cache] (0x0400): [RID#7] smb_uri: smb://sambadc.test.lan/sysvol/test.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Microsoft/Windows NT/SecEdit/GptTmpl.inf
   * (2022-07-02 0:21:26): [gpo_child[4606]] [copy_smb_file_to_gpo_cache] (0x0020): [RID#7] smbc_getFunctionOpen failed [2][No such file or directory]

root@j-client-1934997:~# login <email address hidden>
Password:
Welcome to Ubuntu 22.04 LTS (GNU/Linux 5.15.0-39-generic x86_64)
(...)
<email address hidden>@j-client-1934997:~$

I then update sssd to the version in proposed:
root@j-client-1934997:~# apt-cache policy sssd
sssd:
  Installed: 2.6.3-1ubuntu3.1
  Candidate: 2.6.3-1ubuntu3.1
  Version table:
 *** 2.6.3-1ubuntu3.1 500
        500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages

Remove the "ad_gpo_access_control = permissive" config which allowed it to work, restart sssd.

Attempt the login again. This time the login works, and the logs stay silent:
root@j-client-1934997:~# login <email address hidden>
Password:
Welcome to Ubuntu 22.04 LTS (GNU/Linux 5.15.0-39-generic x86_64)
(...)
Last login: Sat Jul 2 00:23:05 UTC 2022 on pts/3
<email address hidden>@j-client-1934997:~$

jammy verification succeeded.

[Marcos Alano (mhalano)]

Changed tag from verification-jammy-jammy (notice the two jammy) per verification-done-jammy (to conclude the verification). I hope it helps.

[Andreas Hasenack (ahasenack)]

Ops, thanks :)

[Chris Halse Rogers (raof)]

An upload of sssd to focal-proposed has been rejected from the upload queue for the following reason: "Patch lp1934997-authentication-fails-gpo-non-existent.patch appears to have unrelated change to Makefile.am; I'm unsure if this makes any functional change to the build, but would appear to be a bit of a landmine for potential future uuploads".

[Christian Ehrhardt  (paelzer)]

Hi Chris,
I do not think this change is unrelated.

The pre-fix code used "strerror" the new one might handle sssd specific error codes and therefore used "sss_strerror" which is provided by util/util_errors[.h/.c] and therefore has to be linked into it.
So adding that is required and IMHO fine to be done in that patch.

util/signal.c on the other hand only provides BlockSignals & CatchSignal which isn't used in any of the gpo_child_* code so it was removed while touching the list of files to link.

Is that sufficient to let is pass on a second try, or did I miss some underlying problem?

[Chris Halse Rogers (raof)]

Hello r0mulux, or anyone else affected,

Accepted sssd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sssd/2.2.3-3ubuntu0.9 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Andreas Hasenack (ahasenack)]

Focal verification

Reproducing the bug:
root@sssdclient:~# apt-cache policy sssd
sssd:
  Installed: 2.2.3-3ubuntu0.8
  Candidate: 2.2.3-3ubuntu0.8
  Version table:
 *** 2.2.3-3ubuntu0.8 500
        500 http://br.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
        500 http://br.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages
        100 /var/lib/dpkg/status

Login fails:
root@sssdclient:~# getent passwd <email address hidden>
<email address hidden>:*:906401103:906400513:testuser:/<email address hidden>:/bin/bash

root@sssdclient:~# login <email address hidden>
Password:

System error

Logs show it tried to fetch a gpo file and failed:
root@sssdclient:~# cat /var/log/sssd/gpo_child.log
(Wed Jul 6 14:07:59 2022) [gpo_child[2738]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [2][No such file or directory]
(Wed Jul 6 14:07:59 2022) [gpo_child[2738]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [2][No such file or directory]
(Wed Jul 6 14:07:59 2022) [gpo_child[2738]] [main] (0x0020): perform_smb_operations failed.[2][No such file or directory].
(Wed Jul 6 14:07:59 2022) [gpo_child[2738]] [main] (0x0020): gpo_child failed!

Adding the "ad_gpo_access_control = permissive" workaround to /etc/sssd/sssd.conf and restarting makes it work:

root@sssdclient:~# login <email address hidden>
Password:
Welcome to Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-1070-kvm x86_64)
(...)
Creating directory '/<email address hidden>'.
<email address hidden>@sssdclient:~$ id
uid=906401103(<email address hidden>) gid=906400513(domain <email address hidden>) groups=906400513(domain <email address hidden>)

Removing the workaround from /etc/sssd/sssd.conf, restarting sssd, purging the cache, confirming the failure one more time:
root@sssdclient:~# vi /etc/sssd/sssd.conf
root@sssdclient:~# systemctl restart sssd
root@sssdclient:~# sssctl cache-remove -o -p -s
Creating backup of local data...
Removing cache files...
root@sssdclient:~# login <email address hidden>
Password:

System error

And now updating sssd to the version in proposed:
root@sssdclient:~# apt-cache policy sssd
sssd:
  Installed: 2.2.3-3ubuntu0.9
  Candidate: 2.2.3-3ubuntu0.9
  Version table:
 *** 2.2.3-3ubuntu0.9 500
        500 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
        100 /var/lib/dpkg/status

Login now works without the workaround:

root@sssdclient:~# grep permissive /etc/sssd/sssd.conf

root@sssdclient:~# login <email address hidden>
Password:
Welcome to Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-1070-kvm x86_64)
(...)
Last login: Wed Jul 6 14:10:29 UTC 2022 on pts/0
<email address hidden>@sssdclient:~$ id
uid=906401103(<email address hidden>) gid=906400513(domain <email address hidden>) groups=906400513(domain <email address hidden>)

And the gpo_child.log (after bumping debug to 2 again) are silent this time.

Focal verification succeeded.

[Launchpad Janitor (janitor)]

This bug was fixed in the package sssd - 2.6.3-1ubuntu3.1

---------------
sssd (2.6.3-1ubuntu3.1) jammy; urgency=medium

  * d/p/lp1934997-authentication-fails-gpo-non-existent.patch:
    Fix authentication failure when GPO is enabled and
    SecEdit/GptTmpl.inf is missing (LP: #1934997).
  * d/p/lp1979350-GPO-ignore-non-ascii-symbols-in-GPT.INI.patch:
    Ignore non-ASCII characters in GPT.INI. (LP: #1979350)
  * Fix "sssctl analyze" (LP: #1979453)
    [ Timo Aaltonen ]
    - d/{python3-libipa-hbac.install,python3-sss.install,
      sssd-tools.install,rules}: Fix Python installation directory
      path.
    [ Sergio Durigan Junior ]
    - d/p/lp1979453-fix-shebang-on-sss_analyze.patch: Fix shebang on
      sss_analyze.

 -- Sergio Durigan Junior <email address hidden> Wed, 22 Jun 2022 12:31:22 -0400

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for sssd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package sssd - 2.2.3-3ubuntu0.9

---------------
sssd (2.2.3-3ubuntu0.9) focal; urgency=medium

  * d/p/lp1934997-authentication-fails-gpo-non-existent.patch:
    Fix authentication failure when GPO is enabled and
    SecEdit/GptTmpl.inf is missing (LP: #1934997).
  * d/p/lp1979350-GPO-ignore-non-ascii-symbols-in-GPT.INI.patch:
    Ignore non-ASCII characters in GPT.INI. (LP: #1979350)

 -- Sergio Durigan Junior <email address hidden> Tue, 21 Jun 2022 14:29:52 -0400