Hi, I have a IPA setup, in trust with active directory. I noticed a strange behaviour in HBAC. In details:
I have a group ("extgroup"), defined as external, containing an active directory user ("user@ad.dom.ain"). I defined a HBAC rule ("allow_AD_ssh") to permit ssh to a host to users belonging to "extgroup", but the HBAC test (performed with "user@ad.dom.ain") fails. I'm sure the cause is the "Who" section of the HBAC rule (if I leave "Anyone" it works). So the HBAC is defined as:
WHO: User group "extgroup" ACCESSING: host I want to give access to SERVICE: sshd
I was pretty sure it was a incompatibility of HBAC rules with external user.
But if I define a standard (POSIX) group (let say "intgroup"), make "extgroup" member of "intgroup" and use "intgroup" in the definition of the (section "who" of) HBAC rule, it works like a charm.
Why direct use of external group is not working? Is it a bug? Or is there a reason I cannot see?
TIA
Cheers, Giulio
On to, 22 loka 2020, Giulio Casella via FreeIPA-users wrote:
Hi, I have a IPA setup, in trust with active directory. I noticed a strange behaviour in HBAC. In details:
I have a group ("extgroup"), defined as external, containing an active directory user ("user@ad.dom.ain"). I defined a HBAC rule ("allow_AD_ssh") to permit ssh to a host to users belonging to "extgroup", but the HBAC test (performed with "user@ad.dom.ain") fails. I'm sure the cause is the "Who" section of the HBAC rule (if I leave "Anyone" it works). So the HBAC is defined as:
WHO: User group "extgroup" ACCESSING: host I want to give access to SERVICE: sshd
I was pretty sure it was a incompatibility of HBAC rules with external user.
But if I define a standard (POSIX) group (let say "intgroup"), make "extgroup" member of "intgroup" and use "intgroup" in the definition of the (section "who" of) HBAC rule, it works like a charm.
Why direct use of external group is not working? Is it a bug? Or is there a reason I cannot see?
There are two parts here: what you can add to HBAC rules on IPA side and what is submitted for evaluation on SSSD side.
On the IPA side, you can add any types of IPA groups to HBAC rules. This is done for a reason -- the same HBAC engine that SSSD uses can be used by other applications as well. You might want to have environments where those applications fill in details for their evaluation using non-POSIX group membership. SSSD doesn't do that, but it is detail of SSSD operation in POSIX environment.
Next part is that trusted AD users and groups do not exist in IPA LDAP storage. Since you cannot have AD users and groups directly in IPA LDAP, you cannot specify them in HBAC rules directly. You can only specify a group that includes a reference to AD user or a group. This group's reference to a trusted AD object is interpreted by SSSD on the client when SSSD builds up a list of groups a specific user belongs to. All group information is POSIX: nested group membership is flattened and merged, only POSIX groups are left.
HBAC rules get applied by SSSD for use in POSIX environment. This means SSSD populates HBAC request information with the user's details as they are seen by glibc's NSS API.
So, for cases where SSSD is the application that applies HBAC rules (100% cases right now over PAM use), HBAC rules get tested against POSIX details of a user. In addition, since HBAC rules only have direct references to groups existing in IPA LDAP, only IPA POSIX groups of that user matter for HBAC resolution.
As a result, for use in PAM authorization, you should always have POSIX group as a subject of an HBAC rule. But FreeIPA and SSSD do allow to apply the same HBAC engine in multiple scenarios, including non-POSIX environment and this is why IPA CLI/UI do not prevent you from adding non-POSIX groups to HBAC rules.
Thanks, this is clarifying the scenario. So the only way to make it work is to have external group belonging to a posix group. And use posix group in HBAC definition. Am I right?
Ciao, gc
On 22/10/2020 13:13, Alexander Bokovoy via FreeIPA-users wrote:
On to, 22 loka 2020, Giulio Casella via FreeIPA-users wrote:
Hi, I have a IPA setup, in trust with active directory. I noticed a strange behaviour in HBAC. In details:
I have a group ("extgroup"), defined as external, containing an active directory user ("user@ad.dom.ain"). I defined a HBAC rule ("allow_AD_ssh") to permit ssh to a host to users belonging to "extgroup", but the HBAC test (performed with "user@ad.dom.ain") fails. I'm sure the cause is the "Who" section of the HBAC rule (if I leave "Anyone" it works). So the HBAC is defined as:
WHO: User group "extgroup" ACCESSING: host I want to give access to SERVICE: sshd
I was pretty sure it was a incompatibility of HBAC rules with external user.
But if I define a standard (POSIX) group (let say "intgroup"), make "extgroup" member of "intgroup" and use "intgroup" in the definition of the (section "who" of) HBAC rule, it works like a charm.
Why direct use of external group is not working? Is it a bug? Or is there a reason I cannot see?
There are two parts here: what you can add to HBAC rules on IPA side and what is submitted for evaluation on SSSD side.
On the IPA side, you can add any types of IPA groups to HBAC rules. This is done for a reason -- the same HBAC engine that SSSD uses can be used by other applications as well. You might want to have environments where those applications fill in details for their evaluation using non-POSIX group membership. SSSD doesn't do that, but it is detail of SSSD operation in POSIX environment.
Next part is that trusted AD users and groups do not exist in IPA LDAP storage. Since you cannot have AD users and groups directly in IPA LDAP, you cannot specify them in HBAC rules directly. You can only specify a group that includes a reference to AD user or a group. This group's reference to a trusted AD object is interpreted by SSSD on the client when SSSD builds up a list of groups a specific user belongs to. All group information is POSIX: nested group membership is flattened and merged, only POSIX groups are left.
HBAC rules get applied by SSSD for use in POSIX environment. This means SSSD populates HBAC request information with the user's details as they are seen by glibc's NSS API. So, for cases where SSSD is the application that applies HBAC rules (100% cases right now over PAM use), HBAC rules get tested against POSIX details of a user. In addition, since HBAC rules only have direct references to groups existing in IPA LDAP, only IPA POSIX groups of that user matter for HBAC resolution.
As a result, for use in PAM authorization, you should always have POSIX group as a subject of an HBAC rule. But FreeIPA and SSSD do allow to apply the same HBAC engine in multiple scenarios, including non-POSIX environment and this is why IPA CLI/UI do not prevent you from adding non-POSIX groups to HBAC rules.
On to, 22 loka 2020, Giulio Casella via FreeIPA-users wrote:
Thanks, this is clarifying the scenario. So the only way to make it work is to have external group belonging to a posix group. And use posix group in HBAC definition. Am I right?
That's what I wrote already in my answer, so yes.
Ciao, gc
On 22/10/2020 13:13, Alexander Bokovoy via FreeIPA-users wrote:
On to, 22 loka 2020, Giulio Casella via FreeIPA-users wrote:
Hi, I have a IPA setup, in trust with active directory. I noticed a strange behaviour in HBAC. In details:
I have a group ("extgroup"), defined as external, containing an active directory user ("user@ad.dom.ain"). I defined a HBAC rule ("allow_AD_ssh") to permit ssh to a host to users belonging to "extgroup", but the HBAC test (performed with "user@ad.dom.ain") fails. I'm sure the cause is the "Who" section of the HBAC rule (if I leave "Anyone" it works). So the HBAC is defined as:
WHO: User group "extgroup" ACCESSING: host I want to give access to SERVICE: sshd
I was pretty sure it was a incompatibility of HBAC rules with external user.
But if I define a standard (POSIX) group (let say "intgroup"), make "extgroup" member of "intgroup" and use "intgroup" in the definition of the (section "who" of) HBAC rule, it works like a charm.
Why direct use of external group is not working? Is it a bug? Or is there a reason I cannot see?
There are two parts here: what you can add to HBAC rules on IPA side and what is submitted for evaluation on SSSD side.
On the IPA side, you can add any types of IPA groups to HBAC rules. This is done for a reason -- the same HBAC engine that SSSD uses can be used by other applications as well. You might want to have environments where those applications fill in details for their evaluation using non-POSIX group membership. SSSD doesn't do that, but it is detail of SSSD operation in POSIX environment.
Next part is that trusted AD users and groups do not exist in IPA LDAP storage. Since you cannot have AD users and groups directly in IPA LDAP, you cannot specify them in HBAC rules directly. You can only specify a group that includes a reference to AD user or a group. This group's reference to a trusted AD object is interpreted by SSSD on the client when SSSD builds up a list of groups a specific user belongs to. All group information is POSIX: nested group membership is flattened and merged, only POSIX groups are left.
HBAC rules get applied by SSSD for use in POSIX environment. This means SSSD populates HBAC request information with the user's details as they are seen by glibc's NSS API. So, for cases where SSSD is the application that applies HBAC rules (100% cases right now over PAM use), HBAC rules get tested against POSIX details of a user. In addition, since HBAC rules only have direct references to groups existing in IPA LDAP, only IPA POSIX groups of that user matter for HBAC resolution.
As a result, for use in PAM authorization, you should always have POSIX group as a subject of an HBAC rule. But FreeIPA and SSSD do allow to apply the same HBAC engine in multiple scenarios, including non-POSIX environment and this is why IPA CLI/UI do not prevent you from adding non-POSIX groups to HBAC rules.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
freeipa-users@lists.fedorahosted.org