sssd

Bug #1934997
Comment #5

Comment 5 for bug 1934997

Revision history for this message

Sergio Durigan Junior (sergiodj) wrote on 2021-07-15 (last edit on 2022-06-20):

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.

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:

Then, in the client machine:

# login
sambaclientdc1 login: john@test.lan
Password:
...
john@test.lan@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.