Created attachment 1943194 [details] /var/log/sssd/sssd_TCLC.org.log Description of problem: login:cjm Password: Permission denied Version-Release number of selected component (if applicable): sssd version: 2.8.2 How reproducible: 100% Steps to Reproduce: 1. Join the Fedora workstation to the Windows AD Domain 2. Log in as a user with known valid credentials. Credentials are known to be good because they have worked for ten years on a Windows workstation domain member. Actual results: login:cjm Password: Permission denied Expected results: login:cjm Password: $ Additional info: # adcli info adcli: specify a domain to discover [root@worx ~]# adcli info tclc.org [domain] domain-name = TCLC.org domain-short = TCLC domain-forest = TCLC.org domain-controller = Aequitas.TCLC.org domain-controller-site = Default-First-Site-Name domain-controller-flags = pdc gc ldap ds kdc timeserv closest writable good-timeserv full-secret ads-web domain-controller-usable = yes domain-controllers = Aequitas.TCLC.org [computer] computer-site = Default-First-Site-Name # adcli show-computer -U sa Password for sa: sAMAccountName: WORX$ userPrincipalName: - not set - msDS-KeyVersionNumber: 3 msDS-supportedEncryptionTypes: 24 dNSHostName: worx.tclc.org servicePrincipalName: RestrictedKrbHost/worx.tclc.org RestrictedKrbHost/WORX host/worx.tclc.org host/WORX operatingSystem: redhat-linux-gnu operatingSystemVersion: - not set - operatingSystemServicePack: - not set - pwdLastSet: 133204401440679346 userAccountControl: 69632 description: - not set -
Looks like GPO policy has syntax errors that prevent it parsing properly and as a result no matching rights to login. Authentication is not a problem, but access control is denied. * (2023-02-09 15:26:26): [be[TCLC.org]] [ad_gpo_cse_step] (0x0400): [RID#5] smb_server: smb://aequitas.tclc.org * (2023-02-09 15:26:26): [be[TCLC.org]] [ad_gpo_cse_step] (0x0400): [RID#5] smb_share: /SysVol * (2023-02-09 15:26:26): [be[TCLC.org]] [ad_gpo_cse_step] (0x0400): [RID#5] smb_path: /TCLC.org/Policies/{B2C631AC-A2F1-41F7-B55C-6C85870D44BD} * (2023-02-09 15:26:26): [be[TCLC.org]] [ad_gpo_cse_step] (0x0400): [RID#5] gpo_guid: {B2C631AC-A2F1-41F7-B55C-6C85870D44BD} * (2023-02-09 15:26:26): [be[TCLC.org]] [ad_gpo_cse_step] (0x0400): [RID#5] retrieving GPO from cache [{B2C631AC-A2F1-41F7-B55C-6C85870D44BD}] .... * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_store_policy_settings] (0x0020): [RID#5] [/var/lib/sss/gpo_cache/TCLC.org/Policies/{B2C631AC-A2F1-41F7-B55C-6C85870D44BD}/Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf]: ini_config_parse failed [5][Input/output error] ********************** BACKTRACE DUMP ENDS HERE ********************************* (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_store_policy_settings] (0x0020): [RID#5] Error (5) on line 16: Equal sign is missing. (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_store_policy_settings] (0x0020): [RID#5] Error (5) on line 17: Equal sign is missing. * ... skipping repetitive backtrace ... (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_store_policy_settings] (0x0020): [RID#5] Error (5) on line 18: Equal sign is missing. * ... skipping repetitive backtrace ... (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_perform_hbac_processing] (0x0040): [RID#5] GPO access check failed: [1432158236](Host Access Denied) Can you please check that policy is syntactically correct?
Hi, this sounds like an issue (https://bugzilla.redhat.com/show_bug.cgi?id=1316164) which should be fixed for quite some time. Can you share the content of /var/lib/sss/gpo_cache/TCLC.org/Policies/{B2C631AC-A2F1-41F7-B55C-6C85870D44BD}/Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf? bye, Sumit
[Unicode] Unicode=yes [Version] signature="$CHICAGO$" Revision=1 [Group Membership] *S-1-5-32-555__Memberof = *S-1-5-32-555__Members = *S-1-5-21-2272066503-1558053515-3376931032-513 *S-1-5-32-544__Memberof = *S-1-5-32-544__Members = *S-1-5-21-2272066503-1558053515-3376931032-1141,*S-1-5-21-2272066503-1558053515-3376931032-512,*S-1-5-21-2272066503-1558053515-3376931032-500,sa,Administrator [System Access] EnableAdminAccount = 0 EnableGuestAccount = 0 [Registry Values] [Service General Setting] "WinRM",2,"" "RemoteRegistry",2,"" "QBCFMonitorService",4,"" [Privilege Rights] SeShutdownPrivilege = *S-1-5-21-2272066503-1558053515-3376931032-1160,*S-1-5-21-2272066503-1558053515-3376931032-519
Created attachment 1943373 [details] \\TCLC.org\SYSVOL\Policies\{B2C631AC-A2F1-41F7-B55C-6C85870D44BD}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf NOTE: This is the copy on the Windows Server 2012R2 Domain Controller.
Hi Folks, I have "diff"d the file on the Windows Server 2012R2 Domain Controller with the copy on my Fedora 37 Workstation and, not surprisingly, found zero differences: /var/lib/sss/gpo_cache/TCLC.org/Policies/{B2C631AC-A2F1-41F7-B55C-6C85870D44BD}/Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf \\TCLC.org\SYSVOL\TCLC.org\Policies\{B2C631AC-A2F1-41F7-B55C-6C85870D44BD}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf? This may be off-topic: I find that I do not have "Redirected Profile Folders" on my Fedora 37 Workstation. Is this a technological failure of my relationship with the domain, meaning when we find and fix this bug, the "Redirected Profile Folders" feature will magically start working, or is this a failure of my expectations that a Fedora 37 Workstation joined to a Windows Domain should work similarly to a Windows Workstation joined to a Windows Domain?
I think your expectations aren't correct. ;) All these GPOs for profile folders are meant for Windows clients, not Linux clients. Specifically, SSSD only interprets access-related GPOs.
With regards to the content of GptTmpl.inf file, it is not a valid ini file, so I guess this is where it causes issues. It might be a bug in SSSD in that it does not process it as a GPO template and treats like a gpt.ini instead. Template files described in MS-GPSB 2.2: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gpsb/fa15485d-ae9f-456e-a08f-81f2e5725a7e For the record, gpt.ini syntax is described in MS-GPOL 2.2.4: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gpol/b0e5c9e8-e858-4a7a-a94a-4a3d0a9d87a2 Samba only can handle the templates for the backup purposes and nothing else.
Hi, looks like the this should really already be fixed by https://bugzilla.redhat.com/show_bug.cgi?id=1316164. For completeness, which version of the libini_config package are you using? bye, Sumit
$ locate libini_config /usr/lib64/libini_config.so.5 /usr/lib64/libini_config.so.5.2.1 /usr/share/doc/libini_config /usr/share/doc/libini_config/COPYING /usr/share/doc/libini_config/COPYING.LESSER $ rpm -iaq | grep libini_config libini_config-1.3.1-52.fc37.x86_64
Hi Folks, I have a bit of a crisis. As of yesterday, no user can login to my windows domain. I get "The sign-in method you're trying to use is not allowed. Please contact network administrator." The administrator account is able to log in. I fear this must be related to the sssd contact with my Active Directory, since that has been no other contact. As nearly as I know, the only modifications to anything Active Directory related has been the result of "adcli join ..." and "realm leave" I *am* able to log on the my domain at my Fedora workstation as "cjm", as long as I have "ad_gpo_ignore_unreadable=true". I have attached the log for the "#ad_gpo_ignore_unreadable=true", which show the "missing equal sign" mystery. Please advise. I'm in a bit or a bind here. I really need to restore my user community access to my domain. Thanks for the help. Chris.
Hi Folks, Sorry about the above post. It is confused in a detail. "ad_gpo_ignore_unreadable" has no relevance to anything; the setting that determines successful login is "access_provider = ad". I have not attached the log, because it doesn't show anything we don't already know. Here is the detail that may be important. From my Fedora workstation, I have been able to logon to the domain with "#access_provider = ad", in spite of "[RID#4] Error (5) on line 16: Equal sign is missing." and I cannot log on to the domain with "access_provider = ad". Notice comment delimiter. Today, nobody (non-administrators) can log on to the domain from anywhere, most importantly their Windows desktop workstations; the failure is "The sign-in method you're trying to use is not allowed. Please contact network administrator." Thanks for the help, Chris.
Hi, it looks like I got irritated by the 'Error (5) on line 16: Equal sign is missing.' messages and forgot the read the attached log properly. The reason for '[RID#5] GPO access check failed: [1432158236](Host Access Denied)' is not the parsing of the GPO file, this in fact worked, because after receiving the parsing error SSSD tries again to read the GPO file with a special option to ignore everything which is not a key-value pair, i.e. ignore lines without an '=' sign. The reason can be seen here: * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] RESULTANT POLICY: * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] gpo_map_type: Interactive * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] allowed_size = 6 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] allowed_sids[0] = S-1-5-21-2272066503-1558053515-3376931032-1153 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] allowed_sids[1] = S-1-5-32-550 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] allowed_sids[2] = S-1-5-32-549 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] allowed_sids[3] = S-1-5-32-548 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] allowed_sids[4] = S-1-5-32-551 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] allowed_sids[5] = S-1-5-32-544 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] denied_size = 0 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] CURRENT USER: * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] user_sid = S-1-5-21-2272066503-1558053515-3376931032-1159 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] group_sids[0] = S-1-5-21-2272066503-1558053515-3376931032-1106 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] group_sids[1] = S-1-5-21-2272066503-1558053515-3376931032-1104 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] group_sids[2] = S-1-5-21-2272066503-1558053515-3376931032-2102 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] group_sids[3] = S-1-5-21-2272066503-1558053515-3376931032-2101 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] group_sids[4] = S-1-5-21-2272066503-1558053515-3376931032-513 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] group_sids[5] = S-1-5-21-2272066503-1558053515-3376931032-1103 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] group_sids[6] = S-1-5-21-2272066503-1558053515-3376931032-1160 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] group_sids[7] = S-1-5-21-2272066503-1558053515-3376931032-2103 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] group_sids[8] = S-1-5-21-2272066503-1558053515-3376931032-2104 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] group_sids[9] = S-1-5-11 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] POLICY DECISION: * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] access_granted = 0 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_access_check] (0x0400): [RID#5] access_denied = 0 * (2023-02-09 15:26:27): [be[TCLC.org]] [ad_gpo_perform_hbac_processing] (0x0040): [RID#5] GPO access check failed: [1432158236](Host Access Denied) So the GPO is expecting that the user is a member of the group with the SID 'S-1-5-21-2272066503-1558053515-3376931032-1153' but the current group-membership of the user does not include this group and access is denied. What kind of group is the group with the SID 'S-1-5-21-2272066503-1558053515-3376931032-1153' and is it expected that the user is a member of this group? From the logs it looks like the PAC was used to determine the group memberships. Can you share your sssd.conf? I'm asking because PAC evaluation was added recently to be on par with additional PAC checks Windows clients started to apply recently as well and you might have configured a different group-membership scheme which might not work with the memberships recorded in the PAC. As a workaround you might want to try to set: pac_check = no_check in the [pac] section of sssd.conf and implicit_pac_responder = false in the [sssd] section of sssd.conf, restart SSSD with removing the cache and try again. bye, Sumit
Hi Sumit, > So the GPO is expecting that the user is a member of the group > with the SID 'S-1-5-21-2272066503-1558053515-3376931032-1153' > but the current group-membership of the user does not include > this group and access is denied. Without knowing what *-1153 is, I can tell you that this user, "cjm", which is me, has no problem authenticating to the same domain controller when logging into a Windows desktop workstation. It would be interesting to translate *-1153 into something I recognize. Can you tell me how I do that? I have a workaround, "#access_provider = ad", but this problem is not so urgent that I need to work around a problem by ignoring it. I think it is far more interesting that my group membership is not recognize by sssd, and that is a puzzle that should be solved. Thanks for the help, Chris.
Hi, can can find the name of the group with the given SID with the help of SSSD's python bindings from the python3-libsss_nss_idmap package: python -c "import pysss_nss_idmap; print(pysss_nss_idmap.getnamebysid('S-1-5-21-2272066503-1558053515-3376931032-1153'))" bye, Sumit
Hi Sumit, *-1153 is "_vmware_", which is not referenced in any of my group policies, nor is user "cjm" a member of that group. It IS, interestingly, alphabetically first on the list. Thanks for the help, Chris.
Hi, what do you mean by 'my group policies'? For access control the GPOs of the host are used and according to the logs the group S-1-5-21-2272066503-1558053515-3376931032-1153 is listed in SeInteractiveLogonRight of the policy 6AC1786C-016F-11D2-945F-00C04fB984F9 which applied to your computer. bye, Sumit
Hi Sumit, When I said "my group policies", I must concede a certain amount of parochialism. I meant the policies I defined. I don't remember every including that group in any of "my" policies. Do your logs tell you the name of that policy? That would be quite helpful. As for the group, "__vmware__", ... there's your bug. There are no members in that group. Interestingly, it also hs no membership in any other group. So, there are two mysteries: 1) How did a group with no members come to restrict anybody from anything? 2) How did a group that is not a member of any other group get pulled into a policy decision? Actually, this is no mystery. Some policy explicitly referenced it. It would be helpful if I knew which policy. Thanks for the help, Chris.
Hi Sumit, It occurred to me that I don't have a complex set of policies and maybe I could learn something. I scrolled through all of my linked policies, from "Default Domain Controller", and "Default Domain", all the way down twenty or so linked GPO Objects. None includes the group "__vmware__". So, I think this leaves something like a policy that allows a lost of contributors, and using my method would require a lot of looking. Since you logs tell you the "__vmware__" in implicated in this, maybe your logs can tell me where. So, recap: "__vmware__" is neither a member of any group, nor has any members in its group. It is not referenced as "Applies to" at the top level of the Group Policy Editor. Thanks for the help, Chris.
Hi Sumit, Any news? Thanks for the help, Chris.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. 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 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 37 entered end-of-life (EOL) status on 2023-12-05. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.