#1479 Hbac logs show wrong rule name granting access
Closed: Invalid None Opened 11 years ago by steeve.

[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


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

Fields changed

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

7 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata