Learn more about these different git repos.
Other Git URLs
[root@rasalghul ~]# ipa hbacrule-find
2 HBAC rules matched
Rule name: allow_all User category: all Host category: all Source host category: all Service category: all Description: Allow all users to access any host from any host Enabled: FALSE Rule name: fuser_sshd Host category: all Source host category: all Enabled: TRUE User Groups: local_ipa_group Service Groups: sshders
Number of entries returned 2
Logs attached
Hbac logs hbac_logs.txt
According to these logs, the allow_all rule had 'ipaenabledflag=TRUE' in LDAP. Thus, it retrieved it and granted access based on it.
The allow_all rule was disabled on the server. Only the fuser_sshd rule is enabled
[root@rasalghul ~]# ipa hbacrule-find -------------------- 2 HBAC rules matched -------------------- Rule name: allow_all User category: all Host category: all Source host category: all Service category: all Description: Allow all users to access any host from any host Enabled: FALSE Rule name: fuser_sshd Host category: all Source host category: all Enabled: TRUE User Groups: local_ipa_group Service Groups: sshders ---------------------------- Number of entries returned 2 ----------------------------
Added a local ipa user to the group that has the sshd hbacrule applied to
[root@rasalghul ~]# ipa group-show local_ipa_group Group name: local_ipa_group Description: Local IPA Group GID: 592000004 Member users: tuser Member groups: ext_test Member of HBAC rule: fuser_sshd
Testing ssh with tuser shows the correct rule granting access
(Thu Aug 16 19:33:45 2012) [sssd[be[ipalab.qe]]] [hbac_shost_attrs_to_rule] (0x2000): Source hosts disabled, setting ALL (Thu Aug 16 19:33:45 2012) [sssd[be[ipalab.qe]]] [hbac_eval_user_element] (0x1000): [3] groups for [tuser] (Thu Aug 16 19:33:45 2012) [sssd[be[ipalab.qe]]] [hbac_eval_user_element] (0x1000): Added group [ipausers] for user [tuser] (Thu Aug 16 19:33:45 2012) [sssd[be[ipalab.qe]]] [hbac_eval_user_element] (0x1000): Added group [local_ipa_group] for user [tuser] (Thu Aug 16 19:33:45 2012) [sssd[be[ipalab.qe]]] [hbac_eval_user_element] (0x2000): Skipping non-group memberOf [ipaUniqueID=00561d94-e228-11e1-a836-525400f8a02f,cn=hbac,dc=ipalab,dc=qe] (Thu Aug 16 19:33:46 2012) [sssd[be[ipalab.qe]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [fuser_sshd]
Steeve, please run the following ldapsearch command on the client:
kinit -k host/<hostname>@REALM ldapsearch -Y GSSAPI -H ldap://ipaserver.domain.com -b cn=hbac,dc=ipalab,dc=qe "(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(|(hostCategory=all)(memberHost=fqdn=rasalghul.ipalab.qe,cn=computers,cn=accounts,dc=ipalab,dc=qe)))"
According to the logs you sent us, this search is returning both rules. That's why the allow_all rule is passing. If you get back the allow_all entry (which should show {{{ipaenabledflag=TRUE}}}, then there's something wrong on the server.
Fields changed
proposed_priority: Important => Undefined
I'm getting "ipaEnabledFlag: TRUE" on ldapsearch. Complete output is given below.
[root@rasalghul ~]# kinit -k host/rasalghul.ipalab.qe@IPALAB.QE [root@rasalghul ~]# echo $? 0 [root@rasalghul ~]# ldapsearch -Y GSSAPI -H ldap://rasalghul.ipalab.qe -b cn=hbac,dc=ipalab,dc=qe "(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(|(hostCategory=all)(memberHost=fqdn=rasalghul.ipalab.qe,cn=computers,cn=accounts,dc=ipalab,dc=qe)))" SASL/GSSAPI authentication started SASL username: host/rasalghul.ipalab.qe@IPALAB.QE SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <cn=hbac,dc=ipalab,dc=qe> with scope subtree # filter: (&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(|(hostCategory=all)(memberHost=fqdn=rasalghul.ipalab.qe,cn=computers,cn=accounts,dc=ipalab,dc=qe))) # requesting: ALL # # 00561d94-e228-11e1-a836-525400f8a02f, hbac, ipalab.qe dn: ipaUniqueID=00561d94-e228-11e1-a836-525400f8a02f,cn=hbac,dc=ipalab,dc=qe sourceHostCategory: all cn: fuser_sshd objectClass: ipaassociation objectClass: ipahbacrule accessRuleType: allow hostCategory: all ipaEnabledFlag: TRUE ipaUniqueID: 00561d94-e228-11e1-a836-525400f8a02f memberUser: cn=local_ipa_group,cn=groups,cn=accounts,dc=ipalab,dc=qe memberService: cn=sshders,cn=hbacservicegroups,cn=hbac,dc=ipalab,dc=qe # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1
milestone: NEEDS_TRIAGE => SSSD 1.9.0 RC1 rhbz: => 0
Steeve pinged me and said he no longer saw the bug. I can't reproduce it either, so I'm going to close it.
Steeve, please reopen if you can reproduce again.
resolution: => worksforme status: new => closed
Metadata Update from @steeve: - Issue set to the milestone: SSSD 1.9.0 RC1
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/2521
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Log in to comment on this ticket.