Bug 1839805

Make sure your AD environment is configured to use AES encryption types for users. System-wide crypto policy in Fedora 32 and above disables RC4-HMAC.

@Alexander: So should this be reassigned to realmd then? I'd expect `realm join` to work. Besides, this is Fedora 31, does the changed crypto policy apply to that as well?

To say anything concrete, we need to see SSSD logs.

Set 

debug_level = 9

in sssd.conf

for [domain/*], [nss], and [pam] sections, restart SSSD and collect /var/log/sssd directory.

Alternatively, you might want to call 'sssctl debug-level 9' before the test if none of applications in the test restarts sssd, this setting will not survive restart.

To pick up sssd logs, you can also do

sssctl logs-fetch /path/to/file.tar

and then attach the file.

Created attachment 1691988 [details]
sssd debug logs

Thanks Alexander for the hints -- I keep forgetting that sssd doesn't log to the journal. The debug logs are quite a mouthful, so I'm not sure which useful extracts to provide. I naïvely grepped for

# grep -ri rc4.*hmac /var/log/sssd/
/var/log/sssd/krb5_child.log:(2020-05-25 13:55:27): [krb5_child[9501]] [sss_child_krb5_trace_cb] (0x4000): [9501] 1590429327.118054: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, rc4-hmac, camellia128-cts, camellia256-cts

but that doesn't seem to be very useful.

> Make sure your AD environment is configured to use AES encryption types for users

Do you happen to have some links for that? A Google search isn't very fruitful, and https://wiki.samba.org/index.php/Samba_Security_Documentation seems to suggest that it's supported already.

I checked the entire /etc in the Samba 4.3.11 container for `grep -ri aes` and `grep -ri rc4`, that is the only hit:

krb5kdc/kdc.conf:        supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3

there is a failure in retrieving GPOs.

in PAM log:
(2020-05-25 13:55:27): [pam] [pam_dp_send_req] (0x0100): Sending request with the following data:
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): domain: cockpit.lan
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): user: Administrator
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): service: sshd
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): tty: ssh
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): ruser: not set
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): rhost: ::1
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): authtok type: 0
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): newauthtok type: 0
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): priv: 1
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): cli_pid: 9499
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): logon name: Administrator
(2020-05-25 13:55:27): [pam] [pam_print_data] (0x0100): flags: 0
(2020-05-25 13:55:27): [pam] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0
(2020-05-25 13:55:28): [pam] [sbus_dispatch] (0x4000): Dispatching.
(2020-05-25 13:55:28): [pam] [pam_dp_send_req_done] (0x0200): received: [4 (System error)][cockpit.lan]
(2020-05-25 13:55:28): [pam] [pam_reply] (0x4000): pam_reply initially called with result [4]: System error. this result might be changed during processing
(2020-05-25 13:55:28): [pam] [filter_responses] (0x0100): [pam_response_filter] not available, not fatal.
(2020-05-25 13:55:28): [pam] [pam_reply] (0x0200): blen: 28
(2020-05-25 13:55:28): [pam] [pam_reply] (0x0200): Returning [4]: System error to the client

from domain log:
(2020-05-25 13:55:28): [be[cockpit.lan]] [read_pipe_handler] (0x0400): EOF received, client finished
(2020-05-25 13:55:28): [be[cockpit.lan]] [gpo_cse_done] (0x0020): ad_gpo_parse_gpo_child_response failed: [22][Invalid argument]
(2020-05-25 13:55:28): [be[cockpit.lan]] [ad_gpo_cse_done] (0x0400): gpo_guid: {31B2F340-016D-11D2-945F-00C04FB984F9}
(2020-05-25 13:55:28): [be[cockpit.lan]] [ad_gpo_cse_done] (0x0040): Unable to retrieve policy data: [22](Invalid argument}
(2020-05-25 13:55:28): [be[cockpit.lan]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.

from GPO child log:
(2020-05-25 13:55:27): [gpo_child[9502]] [main] (0x0400): performing smb operations
(2020-05-25 13:55:27): [gpo_child[9502]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://f0.cockpit.lan/sysvol/cockpit.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(2020-05-25 13:55:28): [gpo_child[9502]] [copy_smb_file_to_gpo_cache] (0x4000): smb_buflen: 20
(2020-05-25 13:55:28): [gpo_child[9502]] [prepare_gpo_cache] (0x4000): smb_path_with_suffix: /cockpit.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(2020-05-25 13:55:28): [gpo_child[9502]] [prepare_gpo_cache] (0x0400): Storing GPOs in /var/lib/sss/gpo_cache/cockpit.lan
(2020-05-25 13:55:28): [gpo_child[9502]] [prepare_gpo_cache] (0x0400): Storing GPOs in /var/lib/sss/gpo_cache/cockpit.lan/Policies
(2020-05-25 13:55:28): [gpo_child[9502]] [prepare_gpo_cache] (0x0400): Storing GPOs in /var/lib/sss/gpo_cache/cockpit.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
(2020-05-25 13:55:28): [gpo_child[9502]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/gpo_cache/cockpit.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INIDQTKDJ]
(2020-05-25 13:55:28): [gpo_child[9502]] [unlink_dbg] (0x2000): File already removed: [/var/lib/sss/gpo_cache/cockpit.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INIDQTKDJ]
(2020-05-25 13:55:28): [gpo_child[9502]] [ad_gpo_parse_ini_file] (0x0400): ini_filename:/var/lib/sss/gpo_cache/cockpit.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI
(2020-05-25 13:55:28): [gpo_child[9502]] [perform_smb_operations] (0x0400): sysvol_gpt_version: 0
(2020-05-25 13:55:28): [gpo_child[9502]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://f0.cockpit.lan/sysvol/cockpit.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(2020-05-25 13:55:28): [gpo_child[9502]] [copy_smb_file_to_gpo_cache] (0x0400): smb_uri: smb://f0.cockpit.lan/sysvol/cockpit.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Microsoft/Windows NT/SecEdit/GptTmpl.inf
(2020-05-25 13:55:28): [gpo_child[9502]] [copy_smb_file_to_gpo_cache] (0x0020): smbc_getFunctionOpen failed [2][No such file or directory]
(2020-05-25 13:55:28): [gpo_child[9502]] [perform_smb_operations] (0x0020): copy_smb_file_to_gpo_cache failed [2][No such file or directory]
(2020-05-25 13:55:28): [gpo_child[9502]] [main] (0x0020): perform_smb_operations failed.[2][No such file or directory].
(2020-05-25 13:55:28): [gpo_child[9502]] [main] (0x0020): gpo_child failed!


So, basically, libsmbclient-based utility in SSSD cannot talk to your AD DC over SMB protocol for specific files (smb://f0.cockpit.lan/sysvol/cockpit.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/MACHINE/Microsoft/Windows NT/SecEdit/GptTmpl.inf) but can do that for others (smb://f0.cockpit.lan/sysvol/cockpit.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI). Note that SSSD tried the path twice, with /Machine/ and /MACHINE/ component replacement. This is expected, SSSD has the following comment in this place:

            /*
             * DCs may use upper case names for the main folder, where GPTs are
             * stored. libsmbclient does not allow us to request case insensitive
             * file name lookups on DCs with case sensitive file systems.
             */


This looks to me like a problem on the server side -- we have GPT.INI in the policy but no machine policy in place, thus no way to retrieve the policy. The corresponding code in SSSD did not change since 2017 aside from replacing debug string prefix to [gpo_child[%pid]].

(In reply to Martin Pitt from comment #5)
> > Make sure your AD environment is configured to use AES encryption types for users
> 
> Do you happen to have some links for that? A Google search isn't very
> fruitful, and https://wiki.samba.org/index.php/Samba_Security_Documentation
> seems to suggest that it's supported already.
> 
> I checked the entire /etc in the Samba 4.3.11 container for `grep -ri aes`
> and `grep -ri rc4`, that is the only hit:
> 
> krb5kdc/kdc.conf:        supported_enctypes = aes256-cts:normal
> arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal
> des:v4 des:norealm des:onlyrealm des:afs3

No, my comment is unrelated. Samba DC should be able to prefer AES encryption types. I thought you are using Microsoft Windows Server.

We run into this bug also on Fedora 32 in V2.3.0, so it's not only restricted to F31.

For a temporary fix, you can downgrade to V2.2.3 with deleting the sss-DB files and rejoining the machine to AD.

Overall it's harder to debug the exact case on F32 right now, because of the AD 'dot' username problem in systemd V245.4 [see: https://ask.fedoraproject.org/t/gui-login-with-sssd-managed-users-fails/6606]. So for a full functional F32 AD integration every one needs sssd V2.2.3 and systemd V245.5 from rawhide which I think isn't the best circumstance to post any log here. But it's the same PAM error on F32.

Hi,

given the failure in the GPO lookup the issue is most probably related to the changes added by https://pagure.io/SSSD/sssd/issue/3324.

As a workaround you can set 'ad_gpo_access_control' to 'disabled' or 'permissive' in the [domain/...] section of sssd.conf to skip the GPO based access control.

Martin, would it be possible to attach SSSD logs from an older version as well so that I can compare what is the effect of the changes in your environment.

bye,
Sumit

Created attachment 1692119 [details]
sssd debug logs with sssd 2.2.3 on F32 (works)

(In reply to Sumit Bose from comment #9)

> As a workaround you can set 'ad_gpo_access_control' to 'disabled' or
> 'permissive' in the [domain/...] section of sssd.conf to skip the GPO based
> access control.

That works very nicely indeed, thanks!

> Martin, would it be possible to attach SSSD logs from an older version as
> well so that I can compare what is the effect of the changes in your
> environment.

Gladly -- attached.

Thanks!

Hi,

thanks for the logs. In the old version the GPO is considered as 'not applicable' and hence SSSD does not try to download it. I the new version, due to changes from https://pagure.io/SSSD/sssd/issue/3324, it now is considered applicable and while trying to load the related data SSSD fails.

I wonder if you can send me some raw data as well. First the LDAP object:

    kinit -k 'X0$@COCKPIT.LAN'
    ldapsearch -H ldap://f0.cockpit.lan -Y GSSAPI -b 'CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=cockpit,DC=lan'

and second the sysvol content:

    smbclient -k '\\f0.cockpit.lan\sysvol'
    smb: \> ls cockpit.lan\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\
    smb: \> ls cockpit.lan\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\

I would expect that the Machine directory is empty, if not, please follow the path as long as possible.

Thanks.

bye,
Sumit

@Sumit: If you prefer, I'm happy to give you ssh access to a running instance that has everything set up. Just send me your public SSH key.

# ldapsearch -H ldap://f0.cockpit.lan -Y GSSAPI -b 'CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=cockpit,DC=lan'
SASL/GSSAPI authentication started
SASL username: X0$@COCKPIT.LAN
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=cockpit,DC=lan> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# {31B2F340-016D-11D2-945F-00C04FB984F9}, Policies, System, cockpit.lan
dn: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=cockpit
 ,DC=lan
objectClass: top
objectClass: container
objectClass: groupPolicyContainer
cn: {31B2F340-016D-11D2-945F-00C04FB984F9}
instanceType: 4
whenCreated: 20200526112825.0Z
whenChanged: 20200526112825.0Z
displayName: Default Domain Policy
uSNCreated: 3585
uSNChanged: 3585
showInAdvancedViewOnly: TRUE
name: {31B2F340-016D-11D2-945F-00C04FB984F9}
objectGUID:: fVb/256RAUCk0sih9OPuig==
flags: 0
versionNumber: 0
systemFlags: -1946157056
objectCategory: CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=cockpi
 t,DC=lan
isCriticalSystemObject: TRUE
gPCFunctionalityVersion: 2
gPCFileSysPath: \\cockpit.lan\sysvol\cockpit.lan\Policies\{31B2F340-016D-11D2-
 945F-00C04FB984F9}
gPCMachineExtensionNames: [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{53D6AB1B-248
 8-11D1-A28C-00C04FB94F17}][{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4
 FB-11D0-A0D0-00A0C90F574B}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1B-2
 488-11D1-A28C-00C04FB94F17}]
gPCUserExtensionNames: [{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE-7020-1
 1D2-842D-00C04FA372D4}][{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-
 11D1-A7CC-0000F87571E3}]
distinguishedName: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=Sy
 stem,DC=cockpit,DC=lan

# User, {31B2F340-016D-11D2-945F-00C04FB984F9}, Policies, System, cockpit.lan
dn: CN=User,CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC
 =cockpit,DC=lan
objectClass: top
objectClass: container
cn: User
instanceType: 4
whenCreated: 20200526112825.0Z
whenChanged: 20200526112825.0Z
uSNCreated: 3586
uSNChanged: 3586
showInAdvancedViewOnly: TRUE
name: User
objectGUID:: BOTZGXz8RU6WORiszMkG+A==
systemFlags: -1946157056
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=cockpit,DC=lan
isCriticalSystemObject: TRUE
distinguishedName: CN=User,CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Polici
 es,CN=System,DC=cockpit,DC=lan

# Machine, {31B2F340-016D-11D2-945F-00C04FB984F9}, Policies, System, cockpit.la
 n
dn: CN=Machine,CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System
 ,DC=cockpit,DC=lan
objectClass: top
objectClass: container
cn: Machine
instanceType: 4
whenCreated: 20200526112825.0Z
whenChanged: 20200526112825.0Z
uSNCreated: 3587
uSNChanged: 3587
showInAdvancedViewOnly: TRUE
name: Machine
objectGUID:: GOx13irBnEKIjwCn6yaNOg==
systemFlags: -1946157056
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=cockpit,DC=lan
isCriticalSystemObject: TRUE
distinguishedName: CN=Machine,CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Pol
 icies,CN=System,DC=cockpit,DC=lan

# search result
search: 4
result: 0 Success

# numResponses: 4
# numEntries: 3


smb: \> ls cockpit.lan\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\
NT_STATUS_OBJECT_NAME_INVALID listing \cockpit.lan\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\

smb: \> ls cockpit.lan\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\
NT_STATUS_OBJECT_NAME_INVALID listing \cockpit.lan\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\

That didn't seem expected, so I went upwards instead:

smb: \> ls cockpit.lan\Policies\
NT_STATUS_OBJECT_NAME_INVALID listing \cockpit.lan\Policies\
smb: \> ls cockpit.lan\Policies
  Policies                            D        0  Tue May 26 07:28:26 2020

		10258432 blocks of size 1024. 4190900 blocks available

It seems to work better with a "*" at the end (NB I don't really know what I'm doing here):

smb: \> ls cockpit.lan\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\*
  .                                   D        0  Tue May 26 07:28:26 2020
  ..                                  D        0  Tue May 26 07:28:26 2020
  GPT.INI                             N       20  Tue May 26 07:28:26 2020
  MACHINE                             D        0  Tue May 26 07:28:26 2020
  USER                                D        0  Tue May 26 07:28:26 2020

		10258432 blocks of size 1024. 4190968 blocks available
smb: \> ls cockpit.lan\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\*
  .                                   D        0  Tue May 26 07:28:26 2020
  ..                                  D        0  Tue May 26 07:28:26 2020

		10258432 blocks of size 1024. 4190968 blocks available

So Machine/ dir is indeed empty.

Hi,

thanks for the offer to access you system directly. If you don't mind I'd prefer to continue the ping-pong here because the steps recorded here might help others to debug GPO related issues as well. But please let me know if you prefer otherwise.

I forgot that the SIDs are not added automatically to the ldapsearch output, can you re-run ldapsearch with

    kinit -k 'X0$@COCKPIT.LAN'
    ldapsearch -H ldap://f0.cockpit.lan -Y GSSAPI -b 'CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=cockpit,DC=lan' cn flags gPCFunctionalityVersion gPCFileSysPath gPCFileSysPath nTSecurityDescriptor

Thanks.

bye,
Sumit

# ldapsearch -H ldap://f0.cockpit.lan -Y GSSAPI -b 'CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=cockpit,DC=lan' cn flags gPCFunctionalityVersion gPCFileSysPath gPCFileSysPath nTSecurityDescriptor
SASL/GSSAPI authentication started
SASL username: X0$@COCKPIT.LAN
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=cockpit,DC=lan> with scope subtree
# filter: (objectclass=*)
# requesting: cn flags gPCFunctionalityVersion gPCFileSysPath gPCFileSysPath nTSecurityDescriptor 
#

# {31B2F340-016D-11D2-945F-00C04FB984F9}, Policies, System, cockpit.lan
dn: CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=cockpit
 ,DC=lan
cn: {31B2F340-016D-11D2-945F-00C04FB984F9}
flags: 0
gPCFunctionalityVersion: 2
gPCFileSysPath: \\cockpit.lan\sysvol\cockpit.lan\Policies\{31B2F340-016D-11D2-
 945F-00C04FB984F9}

# User, {31B2F340-016D-11D2-945F-00C04FB984F9}, Policies, System, cockpit.lan
dn: CN=User,CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC
 =cockpit,DC=lan
cn: User

# Machine, {31B2F340-016D-11D2-945F-00C04FB984F9}, Policies, System, cockpit.la
 n
dn: CN=Machine,CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System
 ,DC=cockpit,DC=lan
cn: Machine

# search result
search: 4
result: 0 Success

# numResponses: 4
# numEntries: 3

wrt. remote debugging, that makes sense -- I'm happy either way, I just know from myself that I prefer local/direct debugging.

Thanks!

*** Bug 1840908 has been marked as a duplicate of this bug. ***

Hi,

thanks for providing access to a test system.

The important items are that a Samba DC was used here and that at least in the initial configuration of the Samba DC the GPO related files for the default domain policy {31B2F340-016D-11D2-945F-00C04FB984F9} are empty.

I'm currently discussing with Samba developers what would be the best way to solve this. However, since in this setup the GPO are empty and as a result using them for access control will give ot benefit using 'ad_gpo_access_control = disabled' is not only a workaround but makes sense.

I keep the ticket open in case the result of the discussion is that SSSD has to deal with it. In this case we have to add code to detect this case and handle it more gracefully.

bye,
Sumit

Thanks Sumit for your debugging efforts!

Naively it feels like manually setting ad_gpo_access_control=disabled on the client side is a hack/workaround. We shouldn't have "unbreak my computer" options to think about. Of course we could add that to our test suite, but we want our testing to represent reality, not being arbitrarily tweaked to work.

The empty machines policy on the server side sound like a more reasonable root cause -- either this is a valid config -- and sssd then should ignore an empty policy; or it is not a valid config, then we should fix our server configuration, and we can file an issue against https://github.com/Fmstrat/samba-domain/blob/master/init.sh to do the right thing by default. That samba setup script doesn't deal with any policy stuff, so at least the default config in Samba 4.3.8 seems wrong. Possibly this is fixed in newer versions, I'm happy to give that a try.

I didn't find some good docs yet how to manage these GPOs -- I found https://wiki.samba.org/index.php/Managing_local_groups_on_domain_members_via_GPO_restricted_groups and https://wiki.samba.org/index.php/Implementing_System_Policies_with_Samba but they both talk about interactively editing the policies with a Windows client. That's not an option for our automated image builds, but hopefully it can be done on the CLI somehow. Does anyone happen to have a pointer here?

Or would it help to entirely remove the Machine\ directory, so that no GPOs are applied? 

Thanks!

(In reply to Martin Pitt from comment #17)
> Thanks Sumit for your debugging efforts!
> 
> Naively it feels like manually setting ad_gpo_access_control=disabled on the
> client side is a hack/workaround. We shouldn't have "unbreak my computer"
> options to think about. Of course we could add that to our test suite, but
> we want our testing to represent reality, not being arbitrarily tweaked to
> work.
> 
> The empty machines policy on the server side sound like a more reasonable
> root cause -- either this is a valid config -- and sssd then should ignore
> an empty policy; or it is not a valid config, then we should fix our server
> configuration, and we can file an issue against

Hi,

since this is the default Samba DC configuration and I would expect the Windows clients do not have an issue with the missing file, SSSD should at least ignore the missing GPO file for the default domain policy in this case. 


> https://github.com/Fmstrat/samba-domain/blob/master/init.sh to do the right
> thing by default. That samba setup script doesn't deal with any policy
> stuff, so at least the default config in Samba 4.3.8 seems wrong. Possibly
> this is fixed in newer versions, I'm happy to give that a try.
> 
> I didn't find some good docs yet how to manage these GPOs -- I found
> https://wiki.samba.org/index.php/
> Managing_local_groups_on_domain_members_via_GPO_restricted_groups and
> https://wiki.samba.org/index.php/Implementing_System_Policies_with_Samba but
> they both talk about interactively editing the policies with a Windows
> client. That's not an option for our automated image builds, but hopefully
> it can be done on the CLI somehow. Does anyone happen to have a pointer here?
> 

Yes, the afaik the currently expected way is to use gpmc on a Windows client to create the GPO file.

David Mulder from S.u.S.E. pointed out that you can create the file Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf
manually with the content:

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

which represents just an empty policy file with a valid header. The UUID/GUID 31B2.... is always the same and represents the default domain policy.


> Or would it help to entirely remove the Machine\ directory, so that no GPOs
> are applied?

No, this won't work, you have to modify or remove entries in the Samba DC LDAP tree but I think creating the file as described above would be easier.

HTH

bye,
Sumit

> 
> Thanks!

Amazing, thanks Sumit! Creating that file with specified  contents works great. That's a nice workaround for the time being, and better than skipping the tests.

I'm having the same problem on Fedora-32.  Just upgraded to sssd 2.3.0-1.fc32 and my AD authentication stopped working.  The workaround described above also works for me, namely

/etc/sssd/sssd.conf
[domain WHATEVER]
ad_gpo_access_control=disabled

(In reply to Charles Butterfield from comment #20)
> I'm having the same problem on Fedora-32.  Just upgraded to sssd
> 2.3.0-1.fc32 and my AD authentication stopped working.  The workaround
> described above also works for me, namely
> 
> /etc/sssd/sssd.conf
> [domain WHATEVER]
> ad_gpo_access_control=disabled

Hi,

I've seen that you commented on https://bugzilla.redhat.com/show_bug.cgi?id=1840908 as well. Are you using Samba as a domain controller or a Windows AD DC. In the Samba case this ticket here is the right on in the other case you most probably see the issue described in https://bugzilla.redhat.com/show_bug.cgi?id=1840908.

bye,
Sumit

Hi,

Possible solution:
a Samba DC should have 'vendorName: Samba Team (https://www.samba.org)' in the rootDSE by default. This can be used to check if we are talking with a Samba DC and if that's the case a missing default policy (31B2F340-016D-11D2-945F-00C04FB984F9) file can be ignored.

bye,
Sumit

Why are we downloading a nonexistent policy? Do we have the default policy hard coded somewhere?

(In reply to Pavel Březina from comment #23)
> Why are we downloading a nonexistent policy? Do we have the default policy
> hard coded somewhere?

Hi,

in the Samba DC default installation the default domain policy (31B2F340-016D-11D2-945F-00C04FB984F9) is defined in LDAP but on the sysvol file-share there is no related file for it. Since Windows clients do not have an issue with this SSSD should not have either.

HTH

bye,
Sumit

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

We have nto seen this any more since September 2020, we just forgot to close the bug. Sorry!

JFTR:

Pushed PR: https://github.com/SSSD/sssd/pull/6051

* `master`
    * 81d67a592315740d13e48b9a29e29baa8cc35638 - ad: gpo: ignore GPO if SecEdit/GptTmpl.inf is missing

Going to be fixed in sssd-2.7+