Hi,
I'm looking at a logfile from one sssd installation and I'm wondering if it's a GPO bug. The relevant part of the logs is:
[sssd[be[example.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn={BCB10A5A-630C-477E-8E2D-996F06E36DBD},cn=policies,cn=system,DC=example,DC=com]. [sssd[be[example.com]]] [sdap_parse_entry] (0x1000): Entry has no attributes [0(Success)]!? [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set [sssd[be[example.com]]] [ad_gpo_sd_process_attrs] (0x0040): sysdb_attrs_get_string failed: [2](No such file or directory) [sssd[be[example.com]]] [ad_gpo_process_gpo_done] (0x0040): Unable to get GPO list: [2](No such file or directory) [sssd[be[example.com]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed. [sssd[be[example.com]]] [ad_gpo_access_done] (0x0040): Ignoring error: [2](No such file or directory); GPO-based access control failed, but GPO is not in enforcing mode. [sssd[be[example.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, <NULL>) [Success (Success)] [sssd[be[example.com]]] [be_pam_handler_callback] (0x0400): SELinux provider doesn't exist, not sending the request to it. [sssd[be[example.com]]] [be_pam_handler_callback] (0x0100): Sending result [0][example.com]
Did anyone see something like this before? Could it be some permissions issue?
I guess we should try searching the policy with ldapsearch, but I wanted to check if anyone encountered this before..
On (04/04/16 13:57), Jakub Hrozek wrote:
Hi,
I'm looking at a logfile from one sssd installation and I'm wondering if it's a GPO bug. The relevant part of the logs is:
[sssd[be[example.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn={BCB10A5A-630C-477E-8E2D-996F06E36DBD},cn=policies,cn=system,DC=example,DC=com]. [sssd[be[example.com]]] [sdap_parse_entry] (0x1000): Entry has no attributes [0(Success)]!? [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set [sssd[be[example.com]]] [ad_gpo_sd_process_attrs] (0x0040): sysdb_attrs_get_string failed: [2](No such file or directory)
It can be either attribute "cn" or gPCFileSysPath #define AD_AT_CN "cn" #define AD_AT_FILE_SYS_PATH "gPCFileSysPath"
If it is a second case then there should be a verbose log message. DEBUG(SSSDBG_TRACE_ALL, "populating attrs for gpo_guid: %s\n", gp_gpo->gpo_guid);
BTW I checked only sssd master because you didn't mention a version.
LS
On Mon, Apr 04, 2016 at 02:30:16PM +0200, Lukas Slebodnik wrote:
On (04/04/16 13:57), Jakub Hrozek wrote:
Hi,
I'm looking at a logfile from one sssd installation and I'm wondering if it's a GPO bug. The relevant part of the logs is:
[sssd[be[example.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn={BCB10A5A-630C-477E-8E2D-996F06E36DBD},cn=policies,cn=system,DC=example,DC=com]. [sssd[be[example.com]]] [sdap_parse_entry] (0x1000): Entry has no attributes [0(Success)]!? [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set [sssd[be[example.com]]] [ad_gpo_sd_process_attrs] (0x0040): sysdb_attrs_get_string failed: [2](No such file or directory)
It can be either attribute "cn" or gPCFileSysPath #define AD_AT_CN "cn" #define AD_AT_FILE_SYS_PATH "gPCFileSysPath"
Yes, unfortunately the two debug messages are the same and I don't have more verbose logs at the moment. But also note the message before: [sssd[be[example.com]]] [sdap_parse_entry] (0x1000): Entry has no attributes [0(Success)]!?
This read to me as if no attributes were downloaded..
If it is a second case then there should be a verbose log message. DEBUG(SSSDBG_TRACE_ALL, "populating attrs for gpo_guid: %s\n", gp_gpo->gpo_guid);
BTW I checked only sssd master because you didn't mention a version.
RHEL-7.2
On 04/04/2016 08:54 AM, Jakub Hrozek wrote:
On Mon, Apr 04, 2016 at 02:30:16PM +0200, Lukas Slebodnik wrote:
On (04/04/16 13:57), Jakub Hrozek wrote:
Hi,
I'm looking at a logfile from one sssd installation and I'm wondering if it's a GPO bug. The relevant part of the logs is:
[sssd[be[example.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn={BCB10A5A-630C-477E-8E2D-996F06E36DBD},cn=policies,cn=system,DC=example,DC=com]. [sssd[be[example.com]]] [sdap_parse_entry] (0x1000): Entry has no attributes [0(Success)]!? [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set [sssd[be[example.com]]] [ad_gpo_sd_process_attrs] (0x0040): sysdb_attrs_get_string failed: [2](No such file or directory)
It can be either attribute "cn" or gPCFileSysPath #define AD_AT_CN "cn" #define AD_AT_FILE_SYS_PATH "gPCFileSysPath"
Yes, unfortunately the two debug messages are the same and I don't have more verbose logs at the moment. But also note the message before: [sssd[be[example.com]]] [sdap_parse_entry] (0x1000): Entry has no attributes [0(Success)]!?
This read to me as if no attributes were downloaded..
Well, the obvious thing to check would be to perform that actual query and see if the GPO entry is indeed missing content (could be a misconfiguration on the AD side). We only request that entry if we're referred over to it, so if it's incomplete, I think throwing an error is probably the right answer.
sssd-devel@lists.fedorahosted.org