401.1.rst

401.1 VPN Access Control

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"

Lab Components

• Grouper
• PSPNG
• OpenLDAP
• Grouper Deployment Guide

Overview

VPN access is currently controlled by an LDAP group. You are not exactly sure who is in the group or what the policy is, but have a general notion of a natural language policy as all active faculty and staff, plus some exceptions. However, people have been added to the VPN ldap group mostly by hand over many years with little to no lifecycle management in place. There is no easy way to determine who should or should not be in the group. We just had a major breach which was facilitated by access to the VPN. The compromised account used in the breach was given to a former consultant and was never deprovisioned. CISO is coming down hard on us to clean up our act!

Exercise 401.1.1 Analyze legacy VPN authoization group

Gain insight into who exactly has access to the VPN based on the cohorts found in the legacy VPN authorization group. We'll do this by using well established reference groups for faculty, staff, and students.

Import Legacy VPN authorization group

First review the legacy VPN authorization group in LDAP.

1. Log in to https://localhost:8443/phpldapadmin/ with username cn=root,dc=internet2,dc=edu and password password
2. Set the Search Filter to "memberOf=cn=vpn_users,ou=groups,dc=internet2,dc=edu" and Search Results to 5000. How many subjects are in vpn_users?

3. Create a vpn folder under the test folder
4. Create a vpn_legacy group to load the ldap group
5. Added Loader settings to the vpn_legacy group (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: dc=internet2,dc=edu
• Schedule: 0 * * * * ?
• Subject source ID: ldap - EDU Ldap
• Subject lookup type: subjectid
• Search scope: SUBTREE_SCOPE
• Priority:
• Subject expression:${loaderLdapElUtils.convertDnToSpecificValue(subjectId)}
• Require members in other group(s):

6. Run Loader diagnostics (Loader actions -> Loader diagnostics -> Run loader diagnostics)

7. Run loader (Loader actions -> Run loader process to sync group)
8. Review loader logs. How many subject added? (Loader actions -> View loader logs)

9. Review vpn_legacy members

Note

The first thing to notice is you can eyeball the types of subjects in the Grouper UI. For small groups this might be sufficient, but our VPN group has hundreds of subjects.

Use group math to gain insight into vpn_legacy

We will use test composite groups to gain insight into the types of cohorts in vpn_legacy by intersecting it with well known reference groups for faculy, staff, and student.

1. Create test:vpn:vpn_faculty group, and make it a composite intersection of ref:faculty with test:vpn:vpn_legacy. This yields faculty count (almost) - aha! This explains those help desk calls! All faculty should automatically have access to VPN by policy, but they don't.

2. Create test:vpn:vpn_staff group, and make it a composite intersection of ref:staff with test:vpn:vpn_legacy. This yields staff count (again almost!). We're also missing some staff.

3. Create test:vpn:vpn_students group, and make it a composite intersect ref:students with test:vpn:vpn_legacy. This yields a small count. As we expected some students have been added to the vpn access control group as exceptions, but we don't know why, when, or by whom.

Hmm, the totals member counts don’t add up...so we have other cohorts too. Who are they? Set up a composite group to filter out "other cohorts".

4. Create a test:vpn:other_cohorts group.
5. Create vpn_facstaffstudent and add vpn_faculty, vpn_staff, vpn_students as members.
6. Make other_cohorts a composite of vpn_legacy - vpn_facstaffstudent

Other cohorts is a relatively small number. We can now eyeball those.

Exercise 401.1.2 Translate natural language policy to digital policy

The natural language policy is "Faculty, staff and exceptions (some students, contractors, etc.)"

1. Use the application template and the policy group template to create a new vpn application folder and policy group called vpn_authorized
2. Select the policy template option "create allow ad hoc group"
3. Add faculty, staff, and to vpn_authorized_allow

1. Compare counts between vpn_legacy and vpn_authorized. vpn_authorized. Why are they different?

Exercise 401.1.3 Export vpn_authorized to OpenLDAP

1. Configure PSPNG to provision group members to OpenLDAP groupOfNames. The following has already been configured for you in grouper-loader.properties.

   .. literalinclude:: examples/401.1.3-pspng-config.properties
        :language: properties
        :lines: 72-
        :caption: /opt/grouper/grouper.apiBinary/conf/grouper-loader.properties
        :name: 401.1.3-pspng-groupofnames
        :linenos:
   

2. Mark vpn_authorized with the PSPNG provision_to attribute with a value of pspng_groupOfNames.

3. Run the CHANGLE_LOG_consumer_pspng_groupOfNames (Miscellaneous -> All deamon jobs -> Job Actions -> Run job now)
4. Log in to https://localhost:8443/phpldapadmin and navigate to ou=groups. Review your new Grouper managed vpn access control group!

5. Open a service ticket to have the network team switch the VPN config to use vpn_authorized.
6. Bask in the glow of IAM greatness... :)

• 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 vpn_adhoc group. There is no way to distinguish different exceptions, and it is not clear who is responsible for lifecycle and attestation.

Exercise 401.1.4 Implement distributed exception management.

We initially added exceptions to single application reference group. This a good step, but we still lack an easy way to know the "who and why" of exceptions. IAM is still getting tickets to add people. In some case, the expiration is known and added, but most are a one way street-- back to old practices. How can we do better?

Organize Exceptions to Policy

Each policy exception is represented by an application specific reference group.

1. Create app:vpn:ref:vpn_consultants. This ACL will be managed by the IAM team.
2. Create app:vpn:ref:vpn_ajohnson409. Management of this ACL will be delegated to a professor.
3. Add each of these ACLs to vpn_adhoc

Professor Johnson's Special Project

Professor Johnson (ajohnson409) runs a special project 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 will create an access control list (ACL) app:vpn:ref:vpn_ajohnson409 to represent subjects that will access resources related to Professor Johnson's special project. In order to delegate management of this ACL to the professor, we must create a security group and grant it appropriate permissions:

1. Create app:vpn:security:vpn_ajohnson409_mgr.
2. Grant vpn_ajohnson_mgr UPDATE and READ to vpn_ajohnson409
3. Add subject ajohnson409 to this security group.
4. Review the privileges on vpn_johnson409

5. In a private browser window, log in to http://localhost:8443/grouper with username ajohnson409 and password password. You should be able to add and remove members from the vpn_ajohnson409 ACL.
6. Add student bsmith458 to vpn_ajohnson409
7. Find bsmith458 in vpn_authorized and trace membership

Exercise 401.1.5 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.

1. 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

2. ref:iam:global_deny was automatically added to the vpn_authorized_deny

   policy group by the policy template.

3. Add 30 day attestation requirements to the vpn_ajohnson409 ACL. (vpn_ajohnson409 -> More actions -> Attestation -> Attestion actions -> Edit attestion settings...)

1. 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 autotmatically sets the membership end date. Let's implement the second approach.

1. Run ./gte-shell 401.1.1 to get a command prompt.
2. Run ./bin/gsh to start the Grouper shell
3. Paste in the following gsh script:

// 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:ref: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");

1. Add jsmith to vpn_consultants and then review the membership end date. (vpn_consultants -> jsmith -> Edit membership and privileges)

Exercise 401.1.5 Does "blee172" have access to VPN?

The CISO is working on a investigation and wants to know if this particular NetID "blee172" has access to the VPN now or in the past 90 days?

1. Navigate to apps:vpn:vpn_authorized.
2. Search for blee172 and trace membership.

Betty currently has access since she is staff. The Point-In-Time (PIT) tables know if she's had access in the last 90 days.

3. Log in to phpMyAdmin (https://localhost:8443/phpmyadmin/) with username root and a blank password.

4. In the database explore, open grouper Views, then go to SQL tab, paste in the following block:

SELECT
    gpm.SUBJECT_ID,
    gpg.NAME,
    FROM_UNIXTIME(gpmav.MEMBERSHIP_START_TIME / 1000000) start_time,
    FROM_UNIXTIME(gpmav.MEMBERSHIP_END_TIME / 1000000) end_time
FROM grouper_pit_memberships_all_v gpmav
    INNER JOIN grouper_pit_groups gpg
        ON gpmav.owner_group_id = gpg.id
    INNER JOIN grouper_pit_members gpm
        ON gpmav.MEMBER_ID = gpm.id
    INNER JOIN grouper_pit_fields gpf
        ON gpmav.field_id = gpf.id
WHERE gpg.name = 'app:vpn:service:policy:vpn_authorized'
AND gpm.subject_type = 'person'
AND gpf.name = 'members'
ORDER BY gpmav.MEMBERSHIP_START_TIME DESC
;

5. Filter rows for blee172. This shows Betty's earliest access was 2019-06-03.

Exercise 401.1.6 VPN access audit or list of NetIDs

CISO wants to know if anyone on this list of NetIDs has access to the VPN? And why?

1. Import the following list to test:vpn:vpn_audit_list

ahenderson36
cpeterson37
jclark39
kbrown62
tpeterson63
pjohnson64
aroberts95
sdavis107
mhenderson109
jvales117
sgrady139
mprice142
mwilliams144
lpeterson153
mvales154
bsmith458

2. Create test:vpn:vpn_audit
3. Edit composite on vpn_audit and create an interection of vpn_authorized and vpn_audit_list. This will tell us who in vpn_audit_list is also in vpn_authorized.
4. Review and trace membership to determine why they have access.

Congrats! All access to VPN is now traceable to natural language policy and known exceptions! Policy is enforced automatically and kept in sync with changing subject attributes. Exceptions are known and managed with a defined attestation lifecycle. Exception managment is distributed and VPN policy participates in the global deny policy.