Hi, on a Red hat 7.1 machine with latest updates, sssd/realmd authentication against AD works until I try to use simple_allow_groups, when access is denied for all with this error:
pam_sss(sshd:account): Access denied for user testuser: 4 (System error)
Setting debug_level = 7, at the end of the log, I see:
(Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [simple_resolve_group_check] (0x1000): The group is still non-POSIX (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [simple_resolve_group_done] (0x0040): Refresh failed (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [simple_check_get_groups_next] (0x0040): Could not resolve name of group with GID 684028039 (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [simple_access_check_done] (0x0040): Could not collect groups of user testuser (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success] (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [be_pam_handler_callback] (0x0100): Sending result [4][MYDOMAIN.COM] (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [be_pam_handler_callback] (0x0100): Sent result [4][MYDOMAIN.COM]
Full log is available but I need to "sanitize" it.
Any help? Thanks in advance -- Mimmo
On Tue, Mar 17, 2015 at 12:08:50PM +0100, Domenico Viggiani wrote:
Hi, on a Red hat 7.1 machine with latest updates, sssd/realmd authentication against AD works until I try to use simple_allow_groups, when access is denied for all with this error:
pam_sss(sshd:account): Access denied for user testuser: 4 (System error)
Setting debug_level = 7, at the end of the log, I see:
(Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [simple_resolve_group_check] (0x1000): The group is still non-POSIX (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [simple_resolve_group_done] (0x0040): Refresh failed (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [simple_check_get_groups_next] (0x0040): Could not resolve name of group with GID 684028039 (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [simple_access_check_done] (0x0040): Could not collect groups of user testuser (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success] (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [be_pam_handler_callback] (0x0100): Sending result [4][MYDOMAIN.COM] (Mon Mar 16 16:57:52 2015) [sssd[be[CERVEDGROUP.COM]]] [be_pam_handler_callback] (0x0100): Sent result [4][MYDOMAIN.COM]
Full log is available but I need to "sanitize" it.
Any help? Thanks in advance
I thought we solved this bug by ignoring the failures..Pavel, is your patch in 7.1 ?
-----Original Message----- I thought we solved this bug by ignoring the failures..Pavel, is your patch in 7.1 ?
I saw the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1170910 and in fact at first I replied there (not much polite).
If not in 7.1, is there some test RPM or do I need to recompile?
Thanks again --
On 03/17/2015 01:28 PM, Domenico Viggiani wrote:
-----Original Message----- I thought we solved this bug by ignoring the failures..Pavel, is your patch in 7.1 ?
Patch should definitely be at least in sssd-1.12.2-58.el7_1.3 Could we see a conf file? Can you resolve any of the allowed groups?
I saw the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1170910 and in fact at first I replied there (not much polite).
If not in 7.1, is there some test RPM or do I need to recompile?
Thanks again
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Tue, Mar 17, 2015 at 01:36:47PM +0100, Pavel Reichl wrote:
On 03/17/2015 01:28 PM, Domenico Viggiani wrote:
-----Original Message----- I thought we solved this bug by ignoring the failures..Pavel, is your patch in 7.1 ?
Patch should definitely be at least in sssd-1.12.2-58.el7_1.3 Could we see a conf file? Can you resolve any of the allowed groups?
Apparently simple_resolve_group_check() returns EAGAIN which bubbles all the way up.
But it would be nice to see the full logfile as well, this would i.e. make sense if we're offline.
On Tue, Mar 17, 2015 at 01:56:32PM +0100, Domenico Viggiani wrote:
-----Original Message----- But it would be nice to see the full logfile as well, this would i.e. make sense if we're offline.
Attached log file (slightly sanitized, to save the innocents).
Thanks again
So far it looks like a bug in SSSD. Are you using ID mapping? (ldap_id_mapping either True or unset).
-----Original Message----- So far it looks like a bug in SSSD. Are you using ID mapping? (ldap_id_mapping either True or unset).
# cat /etc/sssd/sssd.conf
[sssd] domains = MYDOMAIN.COM config_file_version = 2 services = nss, pam default_domain_suffix= MYDOMAIN.COM debug_level = 7
[pam] debug_level = 7
[domain/MYDOMAIN.COM] ad_domain = MYDOMAIN.COM krb5_realm = MYDOMAIN.COM realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True # use_fully_qualified_names = True fallback_homedir = /home/AD/%u override_homedir = /home/AD/%u access_provider = simple simple_allow_groups = ITAD debug_level = 7
On Tue, Mar 17, 2015 at 02:48:25PM +0100, Domenico Viggiani wrote:
-----Original Message----- So far it looks like a bug in SSSD. Are you using ID mapping? (ldap_id_mapping either True or unset).
# cat /etc/sssd/sssd.conf
[sssd] domains = MYDOMAIN.COM config_file_version = 2 services = nss, pam default_domain_suffix= MYDOMAIN.COM debug_level = 7
[pam] debug_level = 7
[domain/MYDOMAIN.COM] ad_domain = MYDOMAIN.COM krb5_realm = MYDOMAIN.COM realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True # use_fully_qualified_names = True fallback_homedir = /home/AD/%u override_homedir = /home/AD/%u access_provider = simple simple_allow_groups = ITAD debug_level = 7
Then I'm 100% sure we have a bug. The group shouldn't have the non-posix flag after it was updated.
Can you tell us anything about this group: (Mon Mar 16 16:57:52 2015) [sssd[be[MYDOMAIN.COM]]] [sdap_save_group] (0x1000): Mapping group [Organigramma] objectSID [S-1-5-21-2248061571-2151176789-1472819363-28039] to unix ID
Is it from the same domain? What type does the group have?
-----Original Message-----
Then I'm 100% sure we have a bug. The group shouldn't have the non- posix flag after it was updated.
Can you tell us anything about this group: (Mon Mar 16 16:57:52 2015) [sssd[be[MYDOMAIN.COM]]] [sdap_save_group] (0x1000): Mapping group [Organigramma] objectSID [S-1-5-21-2248061571- 2151176789-1472819363-28039] to unix ID
Is it from the same domain? What type does the group have?
Searching for name "Organigramma", I get three results:
dn: OU=Organigramma,OU=Liste di Distribuzione,DC=mydomain,DC=COM objectClass: top objectClass: organizationalUnit ou: Organigramma distinguishedName: OU=Organigramma,OU=Liste di Distribuzione,DC=mydomain,DC=COM instanceType: 4 whenCreated: 20101126102942.0Z whenChanged: 20140418020006.0Z uSNCreated: 20870 uSNChanged: 67370177 name: Organigramma objectGUID:: c/R2xV8yz0mMukbMaENFBg== objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=MYDOMAIN,DC=COM dSCorePropagationData: 20141218110346.0Z dSCorePropagationData: 20140418020006.0Z dSCorePropagationData: 20140418020005.0Z dSCorePropagationData: 20140417070826.0Z dSCorePropagationData: 16010101000001.0Z
dn: OU=Organigramma,OU=Gruppi,DC=mydomain,DC=COM objectClass: top objectClass: organizationalUnit ou: Organigramma distinguishedName: OU=Organigramma,OU=Gruppi,DC=mydomain,DC=COM instanceType: 4 whenCreated: 20101220130013.0Z whenChanged: 20140418020006.0Z uSNCreated: 21089 uSNChanged: 67370180 name: Organigramma objectGUID:: T4yuIBHylkKkdGf8XBmUDw== objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=MYDOMAIN,DC=COM dSCorePropagationData: 20141218110346.0Z dSCorePropagationData: 20140418020006.0Z dSCorePropagationData: 20140418020005.0Z dSCorePropagationData: 20140417070826.0Z dSCorePropagationData: 16010101000001.0Z
dn: CN=Organigramma,OU=Qualita,OU=Gruppi,DC=mydomain,DC=COM objectClass: top objectClass: group cn: Organigramma member: CN=AFLI-Affari Legali ed Istituzionali,OU=Qualita,OU=Gruppi,DC=MYDOMAIN,DC=COM member: CN=Q-AMM-DELEGATO,OU=Qualita,OU=Gruppi,DC=mydomain,DC=COM member: CN=DGOP-Direzione Generale Operativa,OU=Qualita,OU=Gruppi,DC=MYDOMAIN,DC=COM member: CN=Area Corporate Development e Investor Relations-Area Corporate D,OU=Qualita,OU=Gruppi,DC=mydomain,DC=COM member: CN=CCMG-Area Credit Management Group,OU=Qualita,OU=Gruppi,DC=MYDOMAIN,DC=COM member: CN=INAU-Internal Audit,OU=Qualita,OU=Gruppi,DC=mydomain,DC=COM member: CN=CORP-Direzione Generale Commerciale,OU=Qualita,OU=Gruppi,DC=MYDOMAIN,DC=COM member: CN=HRCD-Area HR e Organizzazione,OU=Qualita,OU=Gruppi,DC=mydomain,DC=COM member: CN=BANC-Area Istituzioni Finanziarie,OU=Qualita,OU=Gruppi,DC=MYDOMAIN,DC=COM member: CN=AMFC-Area Amministrazione Finanza e Controllo,OU=Qualita,OU=Gruppi,DC=mydomain,DC=COM member: CN=Q-DIRETTORI,OU=Qualita,OU=Gruppi,DC=mydomain,DC=COM distinguishedName: CN=Organigramma,OU=Qualita,OU=Gruppi,DC=mydomain,DC=COM instanceType: 4 whenCreated: 20150313071410.0Z whenChanged: 20150314030012.0Z uSNCreated: 110805040 uSNChanged: 110852488 name: Organigramma objectGUID:: Pi1+wly0FEGdB/kQRNHWcA== objectSid:: AQUAAAAAAAUVAAAAg7L+hVVaOICjcMlXh20AAA== sAMAccountName: Organigramma sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=mydomain,DC=COM dSCorePropagationData: 20150314030012.0Z dSCorePropagationData: 16010101000000.0Z
On (17/03/15 13:56), Domenico Viggiani wrote:
-----Original Message----- But it would be nice to see the full logfile as well, this would i.e. make sense if we're offline.
Attached log file (slightly sanitized, to save the innocents).
These lines look suspicious.
[sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for [testuser] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=IT-Area IT,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=DGOP-Direzione Generale Operativa,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=Organigramma,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=IT-Infrastruttura IT,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping
We recently added to sssd some extra debug messages which could help with identification of problem.
I can prepare you testing repo I need to know which platform do you want to test? rhel/fedora
LS
On (18/03/15 10:25), Lukas Slebodnik wrote:
On (17/03/15 13:56), Domenico Viggiani wrote:
-----Original Message----- But it would be nice to see the full logfile as well, this would i.e. make sense if we're offline.
Attached log file (slightly sanitized, to save the innocents).
These lines look suspicious.
[sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for [testuser] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=IT-Area IT,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=DGOP-Direzione Generale Operativa,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=Organigramma,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=IT-Infrastruttura IT,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping
We recently added to sssd some extra debug messages which could help with identification of problem.
I can prepare you testing repo I need to know which platform do you want to test? rhel/fedora
I got another idea which could help you. By default we use tokengroups for obtaining group membership it is faster. But it caused some problems in your case so you can try do disable this feature.
Try to put "ldap_use_tokengroups = false" into domain section of sssd.conf. It is workaround which can help nevertheless we want to fix your initial bug.
LS
-----Original Message----- I got another idea which could help you. By default we use tokengroups for obtaining group membership it is faster. But it caused some problems in your case so you can try do disable this feature.
Try to put "ldap_use_tokengroups = false" into domain section of sssd.conf. It is workaround which can help nevertheless we want to fix your initial bug.
BUM! It works!
Neverthless, if I can help to fix the bug, tell me how to test the RPM with extra debug messages under RHEL 7.1.
Thanks again --
On Wed, Mar 18, 2015 at 10:31:05AM +0100, Lukas Slebodnik wrote:
On (18/03/15 10:25), Lukas Slebodnik wrote:
On (17/03/15 13:56), Domenico Viggiani wrote:
-----Original Message----- But it would be nice to see the full logfile as well, this would i.e. make sense if we're offline.
Attached log file (slightly sanitized, to save the innocents).
These lines look suspicious.
[sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for [testuser] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=IT-Area IT,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=DGOP-Direzione Generale Operativa,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=Organigramma,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=IT-Infrastruttura IT,cn=groups,cn=MYDOMAIN.COM,cn=sysdb]. Skipping
We recently added to sssd some extra debug messages which could help with identification of problem.
I can prepare you testing repo I need to know which platform do you want to test? rhel/fedora
I got another idea which could help you. By default we use tokengroups for obtaining group membership it is faster. But it caused some problems in your case so you can try do disable this feature.
Try to put "ldap_use_tokengroups = false" into domain section of sssd.conf. It is workaround which can help nevertheless we want to fix your initial bug.
Yes, the problem is that during tokengroups we save the group as: name=$SID,$DN objectSID: $SID isPosix: false then when the simple access provider resolves the group in order to learn the name, the group should become: name=$NAME,$DN objectSID: $SID
isPosix defaults to True. We need to find out why we don't remove the isPosix:False from the group object.
On (18/03/15 10:39), Domenico Viggiani wrote:
-----Original Message----- I got another idea which could help you. By default we use tokengroups for obtaining group membership it is faster. But it caused some problems in your case so you can try do disable this feature.
Try to put "ldap_use_tokengroups = false" into domain section of sssd.conf. It is workaround which can help nevertheless we want to fix your initial bug.
BUM! It works!
Neverthless, if I can help to fix the bug, tell me how to test the RPM with extra debug messages under RHEL 7.1.
I prepared COPR repository[1] with latest snapshot of sssd-1.12. Please test packages on non production system.
I would like to see log file with high verbosity (0xfff0) and with enabled tokengroups.
LS
[1] https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/
I prepared COPR repository[1] with latest snapshot of sssd-1.12. Please test packages on non production system.
I would like to see log file with high verbosity (0xfff0) and with enabled tokengroups.
LS
[1] https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/
I'm having some dependencies problems with 'libcollection' and 'libini', i.e.:
Error: Package: sssd-ldap-1.12.5-0.20150318.1433.git4b6ee69.sssd_1_12.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) Requires: libcollection.so.4()(64bit) Available: libcollection-0.6.2-22.1.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) libcollection.so.4()(64bit) Installed: libcollection-0.6.2-24.el7.x86_64 (@rhel-x86_64-server-7) ~libcollection.so.2()(64bit) Available: libcollection-0.6.2-22.el7.i686 (rhel-x86_64-server-7) Not found Error: Package: sssd-common-1.12.5-0.20150318.1433.git4b6ee69.sssd_1_12.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) Requires: libini_config.so.5()(64bit) Available: libini_config-1.1.0-22.1.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) libini_config.so.5()(64bit) Installed: libini_config-1.1.0-24.el7.x86_64 (@rhel-x86_64-server-7) ~libini_config.so.3()(64bit) Available: libini_config-1.0.0.1-22.el7.i686 (rhel-x86_64-server-7) Not found
On (19/03/15 09:46), Domenico Viggiani wrote:
I prepared COPR repository[1] with latest snapshot of sssd-1.12. Please test packages on non production system.
I would like to see log file with high verbosity (0xfff0) and with enabled tokengroups.
LS
[1] https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/
I'm having some dependencies problems with 'libcollection' and 'libini', i.e.:
Error: Package: sssd-ldap-1.12.5-0.20150318.1433.git4b6ee69.sssd_1_12.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) Requires: libcollection.so.4()(64bit) Available: libcollection-0.6.2-22.1.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) libcollection.so.4()(64bit) Installed: libcollection-0.6.2-24.el7.x86_64 (@rhel-x86_64-server-7) ~libcollection.so.2()(64bit) Available: libcollection-0.6.2-22.el7.i686 (rhel-x86_64-server-7) Not found Error: Package: sssd-common-1.12.5-0.20150318.1433.git4b6ee69.sssd_1_12.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) Requires: libini_config.so.5()(64bit) Available: libini_config-1.1.0-22.1.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) libini_config.so.5()(64bit) Installed: libini_config-1.1.0-24.el7.x86_64 (@rhel-x86_64-server-7) ~libini_config.so.3()(64bit) Available: libini_config-1.0.0.1-22.el7.i686 (rhel-x86_64-server-7) Not found
That's my fault. I'll prepare new build.
LS
On (19/03/15 09:46), Domenico Viggiani wrote:
I prepared COPR repository[1] with latest snapshot of sssd-1.12. Please test packages on non production system.
I would like to see log file with high verbosity (0xfff0) and with enabled tokengroups.
LS
[1] https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/
I'm having some dependencies problems with 'libcollection' and 'libini', i.e.:
Error: Package: sssd-ldap-1.12.5-0.20150318.1433.git4b6ee69.sssd_1_12.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) Requires: libcollection.so.4()(64bit) Available: libcollection-0.6.2-22.1.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) libcollection.so.4()(64bit) Installed: libcollection-0.6.2-24.el7.x86_64 (@rhel-x86_64-server-7) ~libcollection.so.2()(64bit) Available: libcollection-0.6.2-22.el7.i686 (rhel-x86_64-server-7) Not found Error: Package: sssd-common-1.12.5-0.20150318.1433.git4b6ee69.sssd_1_12.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) Requires: libini_config.so.5()(64bit) Available: libini_config-1.1.0-22.1.el7.centos.x86_64 (lslebodn-sssd-1-12-latest) libini_config.so.5()(64bit) Installed: libini_config-1.1.0-24.el7.x86_64 (@rhel-x86_64-server-7) ~libini_config.so.3()(64bit) Available: libini_config-1.0.0.1-22.el7.i686 (rhel-x86_64-server-7) Not found
There was an issue with build queue, so it took litle bit longer.
The dependency problem should be fixed now.
LS
-----Original Message-----
There was an issue with build queue, so it took litle bit longer.
The dependency problem should be fixed now.
Installed, restarted services sssd/realmd, problem replicated but log SEEMS the same. Log attached.
Thanks --
On (19/03/15 14:23), Domenico Viggiani wrote:
-----Original Message-----
There was an issue with build queue, so it took litle bit longer.
The dependency problem should be fixed now.
Installed, restarted services sssd/realmd, problem replicated but log SEEMS the same. Log attached.
Almost the same log.
[sdap_ad_tokengroups_initgr_mapping_done] (0x1000): Processing membership SID [S-1-5-21-2248061571-2151176789-1472819363-28167] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000): SID [S-1-5-21-2248061571-2151176789-1472819363-28167] maps to GID [684028167] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000): Processing membership SID [S-1-5-21-2248061571-2151176789-1472819363-6709] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000): SID [S-1-5-21-2248061571-2151176789-1472819363-6709] maps to GID [684006709] [sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for [testuser] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such attribute](16)[attribute 'member': no matching attribute value while deleting attribute on 'name=DGOP-Direzione Generale Operativa,cn=groups,cn=mydomain.COM,cn=sysdb'] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=DGOP-Direzione Generale Operativa,cn=groups,cn=mydomain.COM,cn=sysdb]. Skipping [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such attribute](16)[attribute 'member': no matching attribute value while deleting attribute on 'name=Organigramma,cn=groups,cn=mydomain.COM,cn=sysdb'] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=Organigramma,cn=groups,cn=mydomain.COM,cn=sysdb]. Skipping [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such attribute](16)[attribute 'member': no matching attribute value while deleting attribute on 'name=IT-Area IT,cn=groups,cn=mydomain.COM,cn=sysdb'] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=IT-Area IT,cn=groups,cn=mydomain.COM,cn=sysdb]. Skipping [sdap_get_initgr_done] (0x1000): Mapping primary group to unix ID
Here is the most important part. I have no idea waht could cause error: attribute 'member': no matching attribute value while deleting attribute on ..
Sumit, Jakub?
LS
On Thu, Mar 19, 2015 at 05:39:21PM +0100, Lukas Slebodnik wrote:
On (19/03/15 14:23), Domenico Viggiani wrote:
-----Original Message-----
There was an issue with build queue, so it took litle bit longer.
The dependency problem should be fixed now.
Installed, restarted services sssd/realmd, problem replicated but log SEEMS the same. Log attached.
Almost the same log.
[sdap_ad_tokengroups_initgr_mapping_done] (0x1000): Processing membership SID [S-1-5-21-2248061571-2151176789-1472819363-28167] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000): SID [S-1-5-21-2248061571-2151176789-1472819363-28167] maps to GID [684028167] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000): Processing membership SID [S-1-5-21-2248061571-2151176789-1472819363-6709] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000): SID [S-1-5-21-2248061571-2151176789-1472819363-6709] maps to GID [684006709] [sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for [testuser] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such attribute](16)[attribute 'member': no matching attribute value while deleting attribute on 'name=DGOP-Direzione Generale Operativa,cn=groups,cn=mydomain.COM,cn=sysdb'] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=DGOP-Direzione Generale Operativa,cn=groups,cn=mydomain.COM,cn=sysdb]. Skipping [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such attribute](16)[attribute 'member': no matching attribute value while deleting attribute on 'name=Organigramma,cn=groups,cn=mydomain.COM,cn=sysdb'] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=Organigramma,cn=groups,cn=mydomain.COM,cn=sysdb]. Skipping [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such attribute](16)[attribute 'member': no matching attribute value while deleting attribute on 'name=IT-Area IT,cn=groups,cn=mydomain.COM,cn=sysdb'] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=IT-Area IT,cn=groups,cn=mydomain.COM,cn=sysdb]. Skipping [sdap_get_initgr_done] (0x1000): Mapping primary group to unix ID
Here is the most important part. I have no idea waht could cause error: attribute 'member': no matching attribute value while deleting attribute on ..
I think the next line tells :-) the attribute wasn't stored in the cache in the first place. Do you think this failure is fatal and terminates the group update? Because I think we need to find out why is the posix=false attribute not being updated in the first place..
Would it be possible to also see the cache dump after the login attempt? # ldbsearch -H /var/lib/sss/db/cache_$domain.ldb
On (19/03/15 17:45), Jakub Hrozek wrote:
On Thu, Mar 19, 2015 at 05:39:21PM +0100, Lukas Slebodnik wrote:
On (19/03/15 14:23), Domenico Viggiani wrote:
-----Original Message-----
There was an issue with build queue, so it took litle bit longer.
The dependency problem should be fixed now.
Installed, restarted services sssd/realmd, problem replicated but log SEEMS the same. Log attached.
Almost the same log.
[sdap_ad_tokengroups_initgr_mapping_done] (0x1000): Processing membership SID [S-1-5-21-2248061571-2151176789-1472819363-28167] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000): SID [S-1-5-21-2248061571-2151176789-1472819363-28167] maps to GID [684028167] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000): Processing membership SID [S-1-5-21-2248061571-2151176789-1472819363-6709] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000): SID [S-1-5-21-2248061571-2151176789-1472819363-6709] maps to GID [684006709] [sdap_ad_tokengroups_update_members] (0x1000): Updating memberships for [testuser] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such attribute](16)[attribute 'member': no matching attribute value while deleting attribute on 'name=DGOP-Direzione Generale Operativa,cn=groups,cn=mydomain.COM,cn=sysdb'] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=DGOP-Direzione Generale Operativa,cn=groups,cn=mydomain.COM,cn=sysdb]. Skipping [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such attribute](16)[attribute 'member': no matching attribute value while deleting attribute on 'name=Organigramma,cn=groups,cn=mydomain.COM,cn=sysdb'] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=Organigramma,cn=groups,cn=mydomain.COM,cn=sysdb]. Skipping [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such attribute](16)[attribute 'member': no matching attribute value while deleting attribute on 'name=IT-Area IT,cn=groups,cn=mydomain.COM,cn=sysdb'] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sysdb_mod_group_member] (0x0400): Error: 14 (Bad address) [sysdb_update_members_ex] (0x0020): Could not remove member [testuser] from group [name=IT-Area IT,cn=groups,cn=mydomain.COM,cn=sysdb]. Skipping [sdap_get_initgr_done] (0x1000): Mapping primary group to unix ID
Here is the most important part. I have no idea waht could cause error: attribute 'member': no matching attribute value while deleting attribute on ..
I think the next line tells :-) the attribute wasn't stored in the cache in the first place. Do you think this failure is fatal and terminates the group update? Because I think we need to find out why is the posix=false attribute not being updated in the first place..
Would it be possible to also see the cache dump after the login attempt? # ldbsearch -H /var/lib/sss/db/cache_$domain.ldb
It can be related, because I was not able to find out any other problematic operation/debug message in log file.
* There was problem with modification of group membership. * Part of this sysdb modification could be a modification of attribute posix.
I agree that output of ldbsearch might help.
LS
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-
Would it be possible to also see the cache dump after the login
attempt?
# ldbsearch -H /var/lib/sss/db/cache_$domain.ldb
Unfortunately, I'm not able to replicate the problem :( This already happened on the first server and now happened again on another server. Tried also to delete cache under /var/lib/sss/db/ but no luck. I'm sorry.
If it can be of some use, I can send you the full cache dump but privately because it can contain a lot of sensitive informations.
Thanks again --
On Fri, Mar 20, 2015 at 11:38:59AM +0100, Domenico Viggiani wrote:
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-
Would it be possible to also see the cache dump after the login
attempt?
# ldbsearch -H /var/lib/sss/db/cache_$domain.ldb
Unfortunately, I'm not able to replicate the problem :( This already happened on the first server and now happened again on another server. Tried also to delete cache under /var/lib/sss/db/ but no luck. I'm sorry.
If it can be of some use, I can send you the full cache dump but privately because it can contain a lot of sensitive informations.
Yes, please.
On 03/20/2015 11:38 AM, Domenico Viggiani wrote:
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-
Would it be possible to also see the cache dump after the login
attempt?
# ldbsearch -H /var/lib/sss/db/cache_$domain.ldb
Unfortunately, I'm not able to replicate the problem :( This already happened on the first server and now happened again on another server. Tried also to delete cache under /var/lib/sss/db/ but no luck. I'm sorry.
If it can be of some use, I can send you the full cache dump but privately because it can contain a lot of sensitive informations.
Thanks again
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Domenico,
would you try this scratch build? https://preichl.fedorapeople.org/sssd/1.12.2/gidfix/
It contains lslebodn's fix for storing gid for non-posix groups.
Thanks!
-----Original Message----- would you try this scratch build? https://preichl.fedorapeople.org/sssd/1.12.2/gidfix/
It contains lslebodn's fix for storing gid for non-posix groups.
Gladly but actually I'm not able to replicate the problem, I don't know if it can be useful for you.
Thank you very much --
On 04/08/2015 04:23 PM, Domenico Viggiani wrote:
-----Original Message----- would you try this scratch build? https://preichl.fedorapeople.org/sssd/1.12.2/gidfix/
It contains lslebodn's fix for storing gid for non-posix groups.
Gladly but actually I'm not able to replicate the problem, I don't know if it can be useful for you.
Thank you very much
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Oh, you solved it already, then I guess there's no need to try this build. Thanks.
-----Original Message----- From: Pavel Reichl
On 04/08/2015 04:23 PM, Domenico Viggiani wrote:
-----Original Message----- would you try this scratch build? https://preichl.fedorapeople.org/sssd/1.12.2/gidfix/
It contains lslebodn's fix for storing gid for non-posix groups.
Gladly but actually I'm not able to replicate the problem, I don't
know if it can be useful for you.
Oh, you solved it already, then I guess there's no need to try this build. Thanks.
FYI
Again same problem on another machine, solved adding: ldap_use_tokengroups = false in /etc/sssd/sssd.conf and restarting service.
Unfortunately, it was a production server and I as not able to try other solutions.
Bye --
On 04/21/2015 03:52 PM, Domenico Viggiani wrote:
-----Original Message----- From: Pavel Reichl
On 04/08/2015 04:23 PM, Domenico Viggiani wrote:
-----Original Message----- would you try this scratch build? https://preichl.fedorapeople.org/sssd/1.12.2/gidfix/
It contains lslebodn's fix for storing gid for non-posix groups.
Gladly but actually I'm not able to replicate the problem, I don't
know if it can be useful for you.
Oh, you solved it already, then I guess there's no need to try this build. Thanks.
FYI
Again same problem on another machine, solved adding: ldap_use_tokengroups = false in /etc/sssd/sssd.conf and restarting service.
Unfortunately, it was a production server and I as not able to try other solutions.
Bye
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Sorry to hear that, but I think we have already identified the issue and patch is available and waiting for its review.
On (21/04/15 15:52), Domenico Viggiani wrote:
-----Original Message----- From: Pavel Reichl
On 04/08/2015 04:23 PM, Domenico Viggiani wrote:
-----Original Message----- would you try this scratch build? https://preichl.fedorapeople.org/sssd/1.12.2/gidfix/
It contains lslebodn's fix for storing gid for non-posix groups.
Gladly but actually I'm not able to replicate the problem, I don't
know if it can be useful for you.
Oh, you solved it already, then I guess there's no need to try this build. Thanks.
FYI
Again same problem on another machine, solved adding: ldap_use_tokengroups = false in /etc/sssd/sssd.conf and restarting service.
Unfortunately, it was a production server and I as not able to try other solutions.
Could you try to reproduce but on non-production system?
Packages from my repo[1] should fix your problem and it should work also with enabled tokengroups.
LS
[1] https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/
sssd-users@lists.fedorahosted.org
-
Domenico Viggiani -
Jakub Hrozek -
Lukas Slebodnik -
Pavel Reichl