Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Showing
7 changed files
with
210 additions
and
65 deletions.
There are no files selected for viewing
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,79 @@ | ||
# Grouper Training Environment - text to copy and paste - 401.1 | ||
|
||
# VPN Access Control part 1 | ||
|
||
## Learning Objectives | ||
|
||
- Use group math and reference groups to analyze legacy authorization groups | ||
- Translate natural language policy into Grouper digital policy | ||
- Implement distributed access management | ||
- Use Grouper to answer access management questions such as “who” and “why” | ||
|
||
## Hands On | ||
|
||
### Analyze legacy VPN authorization group | ||
|
||
Gain insight into who has access to VPN based on the vpn_users LDAP group. We’ll do this by using well established reference groups for faculty, staff, and students. First review the legacy VPN authorization group in LDAP. | ||
|
||
* Log in to https://localhost:8443/phpldapadmin with username `cn=root,dc=internet2,dc=edu` and password `password` | ||
* Expand ou=groups, and click on cn=vpn_users. Note the multi-valued "member" field. | ||
* Create a `vpn` folder under the test folder. | ||
* Create a `vpn_legacy` group to load the ldap group | ||
* Add Loader settings to _vpn_legacy_ (More -> Loader -> Loader actions -> Edit loader configuration) | ||
- Loader: Yes, has loader configuration | ||
- Source Type: LDAP | ||
- Loader type: LDAP_SIMPLE | ||
- Server ID: demo | ||
- LDAP filter: `(cn=vpn_users)` | ||
- Subject attribute name: `member` | ||
- Search base DN: `ou=groups,dc=internet2,dc=edu` | ||
- Schedule: `0 * * * * ?` | ||
- Subject source ID: eduLDAP - EDU Ldap | ||
- Subject lookup type: subjectIdentifier | ||
- Search scope: SUBTREE_SCOPE | ||
- Priority: | ||
- Subject expression: `${loaderLdapElUtils.convertDnToSpecificValue(subjectId)}` | ||
- Require members in other group(s): | ||
- Schedule job: Yes, schedule and enable this job | ||
* Run Loader diagnostics (Loader actions -> Loader diagnostics -> Run loader diagnostics) | ||
* Run loader (Loader actions -> Run loader process to sync group) | ||
* Review loader logs. How many subjects were added? (Loader actions -> View loader logs) | ||
* Review _vpn_legacy_ members | ||
|
||
### Analyze legacy VPN members | ||
|
||
We will use test composite groups to gain insight into the type of cohorts in vpn_legacy by intersecting it with well known reference groups for faculty and staff. | ||
|
||
* Create group `test:vpn:vpn_facstaff` and make it a composite intersection of _ref:role:all_facstaff_ and _test:vpn:vpn_legacy_. This represents existing faculty/staff with VPN access | ||
* Create group `test:vpn:vpn_legacy_exceptions` and make it a complement group of _vpn_legacy_ minus _all_facstaff_. This shows users who have VPN access but are not faculty or staff | ||
|
||
Another way to get the non-Faculty/Staff users is to use a membership filter. Use advanced membership search Group filter on the _vpn_legacy_ group to only see subjects that are not faculty/staff. | ||
|
||
### Get a list of current exceptions | ||
|
||
Before going live with the new group, we want to have the current exceptions looked at | ||
|
||
* Export the membership of _test:vpn:vpn_legacy_exceptions_ (More actions -> Export Members) | ||
|
||
### Get a list of current exceptions (Extra) | ||
|
||
If the exception list is long, it will speed up review by listing the basis groups for each user | ||
|
||
* Run the SQL query from the Copy/paste to summarize basis groups for the exceptions | ||
|
||
|
||
``` | ||
select distinct M.subject_id, M.subject_identifier0, M.name, group_concat(distinct G.display_extension) as "Basis Groups" from grouper_memberships_all_v V | ||
join grouper_members M on V.member_id = M.id | ||
join grouper_groups G on V.owner_group_id = G.id | ||
where (G.name like 'basis:hr:employee:dept:%' or G.name like 'basis:sis:prog_status:year:%') | ||
and M.subject_source = 'eduLDAP' | ||
and M.subject_id in ( | ||
select distinct subject_id from grouper_memberships_all_v V | ||
join grouper_members M on V.member_id = M.id | ||
join grouper_groups G on V.owner_group_id = G.id | ||
where G.name = 'test:vpn:vpn_legacy_exceptions' | ||
and M.subject_source = 'eduLDAP' | ||
) group by M.subject_id | ||
order by M.subject_id; | ||
``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,112 @@ | ||
# Grouper Training Environment - text to copy and paste - 401.2 | ||
|
||
# VPN Access Control part 2 | ||
|
||
## Hands On | ||
|
||
### Translate natural language policy to digital policy | ||
|
||
The natural language policy is "Faculty, staff, and some exceptions (students, contractors, etc)" | ||
|
||
* Use the application template and the policy group template to create a new `vpn` application folder | ||
* Create a policy group called `vpn_authorized`. Select the policy template option "create allow ad hoc group" | ||
* Add the _All Faculty/Staff_ group to _vpn_authorized_allow_ | ||
|
||
### Review provisioner | ||
|
||
* Go to Miscellaneous > Provisioning->groupOfNames->Actions->Edit provisioner | ||
|
||
In this provisioner, a group will sync to a record in LDAP in the _ou=Groups_ tree. The _cn_ value will be the full group name. The _member_ attribute will be multi-valued, containing the LDAP Dn values for the groups' members | ||
|
||
### Review full sync provisioning job | ||
|
||
A full sync provisioner has already been created for you. Review its status | ||
|
||
* Go to Miscellaneous->Daemon jobs | ||
* Filter for job name `OTHER_JOB_groupOfNames_full_sync` | ||
* Click on Edit daemon | ||
|
||
### Provision vpn_authorized to OpenLDAP | ||
|
||
* Configure provisioning on _app:vpn:service:policy:vpn_authorized_ | ||
* Run the full sync provisioner job | ||
* Log in to https://localhost:8443/phpldapadmin and navigate to _ou=groups_. Review your new Grouper managed vpn access control group! | ||
|
||
|
||
* Investigate exceptions and add to the ad-hoc group as needed | ||
* *Open a service ticket to have the network team switch the VPN config to use vpn_authorized. | ||
|
||
Some important goals have been accomplished: | ||
- Automatic provisioning/deprovisioning of VPN access for faculty and staff. | ||
- Natural language policy - clear and visible. | ||
- Exceptions management | ||
|
||
This is a huge improvement! However, we are still dealing with tickets to add and remove subjects (well at least to add!) to the ad-hoc group. There is no way to distinguish different exceptions, and it is not clear who is responsible for lifecycle and attestation. | ||
|
||
### Implement distributed exception management | ||
|
||
Each policy exception is represented by an application specific access control lists (ACL). | ||
|
||
* Create `app:vpn:service:policy:vpn_consultants`. This ACL will be managed by the IAM team. | ||
* Create `app:vpn:service:policy:vpn_wri250`. Management of this ACL will be delegated to a course instructor. | ||
* Add each of these ACLs to _vpn_authorized_allow_manual_ | ||
|
||
Professor Jenkins (`kjenkins`) runs a special project for course WRI250 that includes various online resources that can only be accessed from the VPN. The professor should be able to control who is allowed to have VPN access for the purpose of accessing his project’s resources. | ||
|
||
We already created an access control list (ACL) _app:vpn:service:policy:vpn_wri250_ to represent subjects that will access resources related to the special project. In order to delegate management of this ACL to the course instructors, we must create a security group and grant it appropriate permissions: | ||
|
||
* Create `app:vpn:security:vpn_wri250_mgr` | ||
* Add the instructors for WRI250 to this security group (hint: there is a basis group for this) | ||
* Grant _vpn_wri250_mgr_ UPDATE and READ to _vpn_wri250_ | ||
* Review the privileges on _vpn_wri250_ | ||
|
||
* In a private browser window, log in to http://localhost:8443/grouper with username `kjenkins` and password `password`. You should be able to add and remove members from the _vpn_wri250_ ACL. | ||
* Add student `mwest` to _vpn_wri250_ | ||
* Switch back to `banderson`. Find `mwest` in _vpn_authorized_ and trace membership | ||
|
||
### Implement additional policy constraints | ||
|
||
It is the IAM team’s responsibility to make sure that VPN access is granted to the correct subjects. Putting some limits in place can help make sure improper access is not granted. Attestation makes sure that access which was granted in the past is still appropriate. | ||
|
||
The ref:iam:global_deny reference group represents a broad cohort of subjects that should not be granted access. Subjects that fall into this category may include: | ||
- Termed with cause | ||
- Deceased | ||
- Other reasons | ||
|
||
ref:iam:global_deny was automatically added to the vpn_authorized_deny | ||
|
||
* As banderson, add 30 day attestation requirements to the _vpn_wri250_ ACL. (vpn_wri250 -> More actions -> Attestation -> Attestation actions -> Edit attestation settings…) | ||
* As `kjenkins`, review attestations (Miscellaneous -> Attestation) | ||
|
||
Consultant exceptions should expire automatically after 180 days. There are 2 techniques to accomplish this in Grouper. The first is to simply edit the membership end date after you have added a subject to a group. The second, and more reliable, is to have a rule that runs every time a subject is added which automatically sets the membership end date. Let’s implement the second approach. | ||
|
||
* Run ./gte-gsh to get a command prompt. | ||
* Paste into the gsh console | ||
|
||
``` | ||
// Automatically expire vpn_consultant subject memberships in 180 days | ||
gs = GrouperSession.startRootSession(); | ||
numberOfDays = 180; | ||
actAs = SubjectFinder.findRootSubject(); | ||
vpn_consultants = GroupFinder.findByName(gs, "app:vpn:service:policy:vpn_consultants"); | ||
attribAssign = vpn_consultants.getAttributeDelegate().addAttribute(RuleUtils.ruleAttributeDefName()).getAttributeAssign(); | ||
attribValueDelegate = attribAssign.getAttributeValueDelegate(); | ||
attribValueDelegate.assignValue(RuleUtils.ruleActAsSubjectSourceIdName(), actAs.getSourceId()); | ||
attribValueDelegate.assignValue(RuleUtils.ruleActAsSubjectIdName(), actAs.getId()); | ||
attribValueDelegate.assignValue(RuleUtils.ruleCheckTypeName(), RuleCheckType.membershipAdd.name()); | ||
attribValueDelegate.assignValue(RuleUtils.ruleThenEnumName(), RuleThenEnum.assignMembershipDisabledDaysForOwnerGroupId.name()); | ||
attribValueDelegate.assignValue(RuleUtils.ruleThenEnumArg0Name(), numberOfDays.toString()); | ||
attribValueDelegate.assignValue(RuleUtils.ruleThenEnumArg1Name(), "T"); | ||
``` | ||
|
||
* Add Ricardo Johnson (`rjohnso5`) to _vpn_consultants_ | ||
* Review Enabled/Disabled status - Membership -> Filter for: -> Advanced -> Enabled/disabled | ||
|
||
### Answering Audit Questions - Does "jadams3" have access to VPN? When? | ||
|
||
The CISO is working on a investigation and wants to know if this particular NetID "jadams3" has access to the VPN now or in the past 90 days? | ||
|
||
* Navigate to _app:vpn:service:policy:vpn_authorized_ | ||
* Search for `jadams3` and trace membership. | ||
|
||
Joseph currently has access since he is staff. The Point-In-Time (PIT) tables know if he’s had access in the last 90 days. These can be access using the advanced membership filter. This shows his earliest access date. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.