Description
Control authorization of trusted domain users (Active Directory users) by a set of HBAC policies
Setup
Before this test, please make sure that you have:
- Installed FreeIPA server (Test Case)
- Configured Trust between Active Directory and FreeIPA server. Configured PuTTy to be able to log in from AD to FreeIPA (Test Case)
How to test
Preparing external group
AD users can be assigned to HBAC policies only if they get assigned a standard FreeIPA group. HBAC policies does not work with AD groups or with external groups that contain AD users (i.e. their SIDs).
In order to prepare HBAC policies which would be able to allow access to AD users, we will first prepare an external group:
# ipa group-add --external ext_ad_administrators --desc "AD.TEST Administrators" ----------------------------------- Added group "ext_ad_administrators" ----------------------------------- Group name: ext_ad_administrators Description: AD.TEST Administrators
Now assign external user to this group (this step assumes that Active Directory domain has a NetBIOS name set to AD:
# ipa group-add-member ext_ad_administrators --external "AD\Domain Admins" [member user]: [member group]: Group name: ext_ad_administrators Description: AD.TEST Administrators External member: S-1-5-21-3035198329-144811719-1378114514-512 ------------------------- Number of members added 1 -------------------------
Add standard POSIX group which will be assigned to this external group, i.e. to AD\Administrator user:
# ipa group-add ad_administrators Description: AD.TEST Administrators ------------------------------- Added group "ad_administrators" ------------------------------- Group name: ad_administrators Description: AD.TEST Administrators GID: 1189600004 # ipa group-add-member ad_administrators --group ext_ad_administrators Group name: ad_administrators Description: AD.TEST Administrators GID: 1189600004 Member groups: ext_ad_administrators ------------------------- Number of members added 1 -------------------------
Now, you AD user Administrator should have assigned a standard POSIX group to himself.
Test new AD user POSIX group
Go to your AD instance and try to logging in and displaying a list of groups that your AD user has assigned by SSSD:
$ id uid=71800500(administrator@ad.test) gid=71800500(administrator@ad.test) groups=71800500(administrator@ad.test),71800512(domain admins@ad.test),71800513(domain users@ad.test),71800518(schema admins@ad.test),71800519(enterprise admins@ad.test),71800520(group policy creator owners@ad.test),1189600004(ad_administrators) context=unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023
If you do not see the new group ad_administrators in the list of groups, you can purge your Kerberos tickets in your AD to make sure that AD user's PAC (additional metadata for Kerberos ticket which also contains list of groups) is recreated and contain the new POSIX group. To purge your AD Kerberos tickets, run the following command in AD command line:
klist purge
Create HBAC policy
Lets 2 new HBAC policies, one allowing SSH access to the FreeIPA server machine to the AD Administrators (i.e. using ad_administrators group) and one allowing SSH access to the FreeIPA server to local admin user.
# ipa hbacrule-add ad_can_login ------------------------------ Added HBAC rule "ad_can_login" ------------------------------ Rule name: ad_can_login Enabled: TRUE # ipa hbacrule-mod ad_can_login --hostcat=all --------------------------------- Modified HBAC rule "ad_can_login" --------------------------------- Rule name: ad_can_login Host category: all Enabled: TRUE # ipa hbacrule-add-user ad_can_login --groups ad_administrators Rule name: ad_can_login Host category: all Enabled: TRUE User Groups: ad_administrators ------------------------- Number of members added 1 ------------------------- # ipa hbacrule-add-service ad_can_login --hbacsvcs login --hbacsvcs sshd Rule name: ad_can_login Host category: all Enabled: TRUE User Groups: ad_administrators Services: login, sshd ------------------------- Number of members added 2 -------------------------
Now the local admin HBAC policy:
# ipa hbacrule-add local_admin_can_login --------------------------------------- Added HBAC rule "local_admin_can_login" --------------------------------------- Rule name: local_admin_can_login Enabled: TRUE [root@ipa db]# ipa hbacrule-add-host local_admin_can_login --hostshostnameRule name: local_admin_can_login Enabled: TRUE Hosts: ipa.linux.ad.test ------------------------- Number of members added 1 ------------------------- # ipa hbacrule-add-host local_admin_can_login --hostshostnameRule name: local_admin_can_login Enabled: TRUE Hosts: ipa.linux.ad.test ------------------------- Number of members added 1 ------------------------- # ipa hbacrule-add-service local_admin_can_login --hbacsvcs login --hbacsvcs sshd Rule name: local_admin_can_login Enabled: TRUE Hosts: ipa.linux.ad.test Services: login, sshd ------------------------- Number of members added 2 ------------------------- # ipa hbacrule-add-user local_admin_can_login --users admin Rule name: local_admin_can_login Enabled: TRUE Users: admin Hosts: ipa.linux.ad.test Services: login, sshd ------------------------- Number of members added 1 -------------------------
Testing new policy with HBAC test
Since FreeIPA 3.1.3, standard FreeIPA hbactest command and a Web UI is able to test HBAC policies also for external users.
Since testing HBAC test for trusted domain users requires LDAP queries to the Trusted domain global catalogue, only members of trust admins group will be able to run these tests as only members of this group are currently authorized to do these searches
You can create a local non-admin user that will be also used to test HBAC policies:
# ipa user-add --first=Test --last=User tuser --password
At first, we will try the new policy for local user admin
# ipa hbactest --user admin --host hostname --service sshd
--------------------
Access granted: True
--------------------
Matched rules: allow_all
Matched rules: local_admin_can_login
Not matched rules: ad_can_login
local_admin_can_login should match.
Lets try the same policy with other local user tuser, local_admin_can_login should not match:
# ipa hbactest --user tuser --host hostname --service sshd
--------------------
Access granted: True
--------------------
Matched rules: allow_all
Not matched rules: ad_can_login
Not matched rules: local_admin_can_login
The test can be now performed also for trusted domain user
This command can take 10-30 seconds to execute as it runs several LDAP queries to Active Directory Global Catalog
# ipa hbactest --user "AD\Guest" --host hostname --service sshd
--------------------
Access granted: True
--------------------
Matched rules: allow_all
Not matched rules: ad_can_login
Not matched rules: local_admin_can_login
As expected, ad_can_login HBAC rule did not match. If tested with AD\Administrator user, it should match:
# ipa hbactest --user "AD\Administrator" --host hostname --service sshd
--------------------
Access granted: True
--------------------
Matched rules: ad_can_login
Matched rules: allow_all
Not matched rules: local_admin_can_login
Testing with disabled allow_all rule
As could have been seen in the hbactest output above, access was always granted because at least the allow_all HBAC rule matched. This is a default FreeIPA HBAC rule added to avoid authentication failures for users who do not want to use HBAC. To make sure, that the new HBAC rules are being enforced, we need to disable allow_all rule first:
# ipa hbacrule-disable allow_all ------------------------------ Disabled HBAC rule "allow_all" ------------------------------
If you now run the tests above now, the Access granted indicator in the output would only depend on the result of the new HBAC rules that were added:
# ipa hbactest --user "AD\Guest" --hosthostname--service sshd --------------------- Access granted: False --------------------- Not matched rules: ad_can_login Not matched rules: local_admin_can_login # ipa hbactest --user "AD\Administrator" --hosthostname--service sshd -------------------- Access granted: True -------------------- Matched rules: ad_can_login Not matched rules: local_admin_can_login
Testing with SSH
You can first try to authenticate to IPA server with ssh as a local user:
$ ssh tuser@server1.ipa.example.org tuser@server1.ipa.example.org's password: Connection closed by UNKNOWN
Access was denied, there was no rule for user tuser. Lets try with admin account:
$ ssh admin@server1.ipa.example.org admin@server1.ipa.example.org's password: -bash-4.2$
Testing with PuTTy
To test the HBAC policies with the trusted domain user account, go to you AD machine, run PuTTy and try to log in to server1.ipa.example.org with Administrator account. You should be allowed to authenticate.
To do a negative test, you can try lo set up PuTTy for another AD user and try to authenticate as well. Alternatively, you can disable the ad_can_login rule and try to log in again.
Cleaning up after the test
Enable allow_all HBAC rule again to not bias the result of other Test Cases you try:
# ipa hbacrule-enable allow_all ----------------------------- Enabled HBAC rule "allow_all" -----------------------------
Expected Results
All the test steps should end with the specified results.