From Fedora Project Wiki

Revision as of 06:52, 9 May 2013 by Stefw (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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:

  1. Installed FreeIPA server (Test Case)
  2. 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 --hosts hostname
  Rule 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 --hosts hostname
  Rule 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.

HBAC Test for trusted domain 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

Execution time for HBAC Test
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" --host hostname --service sshd
---------------------
Access granted: False
---------------------
  Not matched rules: ad_can_login
  Not matched rules: local_admin_can_login

# ipa hbactest --user "AD\Administrator" --host hostname --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.

Retrieved from "https://fedoraproject.org/w/index.php?title=QA:Testcase_freeipav3_ad_hbac&oldid=336242"