Activating enveloping

This procedure involves defining resources in the RACFEVNT class, and activating this class.

Define the RACFEVNT resources to control enveloping. You can define each resource separately (PASSWORD.ENVELOPE and PASSPHRASE.ENVELOPE) or define a generic profile (shown in Example 2) to control both. The APPLDATA field of this profile specifies the hash algorithm to use when signing the PKCS #7 envelope, and the encryption strength to use when encrypting the envelope. The following examples specify the strongest signing and encryption:
Example 1:
```
RDEFINE RACFEVNT PASSWORD.ENVELOPE   UACC(NONE) APPLDATA('MD5/STRONG')
RDEFINE RACFEVNT PASSPHRASE.ENVELOPE UACC(NONE) APPLDATA('MD5/STRONG')
```
Example 2:
```
SETROPTS GENERIC(RACFEVNT) 
RDEFINE RACFEVNT PASS*.ENVELOPE UACC(NONE) APPLDATA('MD5/STRONG')
```
Example 3: If you previously implemented password enveloping by defining the PASSWORD.ENVELOPE resource and want to add support for password phrases using a generic profile (shown in Example 2), you can model the new generic profile on your previously defined resource and then delete the old profile. For example:
```
SETROPTS GENERIC(RACFEVNT) 
RDEFINE RACFEVNT PASS*.ENVELOPE FROM(PASSWORD.ENVELOPE)
RDELETE RACFEVNT PASSWORD.ENVELOPE
```
Guidelines:
- Define separate discrete profiles (as shown in Example 1) if you need the flexibility to envelope only passwords or only password phrases. Using separate profiles also allows you to authorize a set of users eligible for password enveloping and a different set eligible for password phrase enveloping. (See Step 2 for information about authorizing users.)
- In general, avoid assigning UACC(READ) to the resources that control enveloping because UACC(READ) enables enveloping for all users (except RESTRICTED users), including highly privileged users such as system-SPECIAL users and user IDs that you use for emergency recovery purposes. Consider assigning UACC(READ) only if you specifically authorize sensitive user IDs with ACCESS(NONE). This prevents their passwords and password phrases from being enveloped.
Enable enveloping for users whose passwords or password phrases are to be encrypted for the intended recipients (whose digital certificates are connected to the IRR.PWENV.KEYRING key ring). This is done by permitting a given user or group to the appropriate envelope resources in the RACFEVNT class.
Example 1:
```
PERMIT PASSWORD.ENVELOPE CLASS(RACFEVNT) ID(USER1 USER2 GROUPA) 
   ACCESS(READ)
PERMIT PASSPHRASE.ENVELOPE CLASS(RACFEVNT) ID(USER1 USER2 GROUPA GROUPB) 
   ACCESS(READ)
```
Example 2:
```
PERMIT PASS*.ENVELOPE CLASS(RACFEVNT) ID(USER1 USER2 GROUPA GROUPB) 
   ACCESS(READ)
```
Restrictions:
- If you specified UACC(READ) in Step 1, you must specifically permit restricted users with ACCESS(READ) by user ID or group if you want their passwords or password phrases to be enveloped. (Restricted user IDs are not authorized by the UACC in profiles.)
- Protected user IDs are not eligible for enveloping because they have no passwords or password phrases.
If you specified UACC(NONE) in Step 1, you must include newly added users and groups into the access scheme so that passwords and password phrases are properly enveloped or not, over time. In particular, you might want to have intended group connections in place for all new users before their initial logons when they must change their passwords and password phrases. Also, keep in mind that if a user is connected to several groups, his effective authority is the highest allowed by any of his groups (assuming he isn't specifically permitted by user ID, in which case this authority overrides that granted by any of his groups).

For example, if list-of-groups processing (SETROPTS GRPLIST option) is active, and user BOB is connected to groups GROUP1 and GROUP2, and GROUP1 is permitted to PASSWORD.ENVELOPE with ACCESS(NONE), GROUP2 is permitted with ACCESS(READ), and BOB is not explicitly permitted, then BOB's effective access to PASSWORD.ENVELOPE is READ, and BOB's password will be enveloped.
Optionally, activate LDAP change log notification for USER profile changes so an LDAP change log entry is created whenever a user's new password or password phrase is enveloped. This step is required if you use an application like IBM® Tivoli® Directory Integrator to implement a heterogeneous password synchronization solution.
Example:
```
RDEFINE RACFEVNT NOTIFY.LDAP.USER UACC(READ)
```
Optionally, you can use a generic profile to activate LDAP change log notification. See LDAP event notification for details.
Enable enveloping by activating the RACFEVNT class. It can be RACLISTed to improve performance but this is not required.
```
SETROPTS CLASSACT(RACFEVNT) RACLIST(RACFEVNT)
```
Stop and restart the RACF® subsystem address space after defining the needed enveloping resources in the RACFEVNT class and activating the RACFEVNT class. If the RACF subsystem address space is already up and running when you configure enveloping and you do not stop and restart the address space, it will not have the proper environment set up to perform the function and will fail any request to envelope passwords or password phrases.