An unrestricted user can use the SAS Deployment Manager or the METADATA procedure to change how stored passwords are encrypted. These methods provide a thorough, secure, and efficient approach for an unrestricted user to address situations such as the following:

• For greater security, you want to re-encrypt stored passwords using a passphrase as the encryption key, instead of using the default fixed key.

• You suspect one or more stored passwords have been compromised, so you want to re-encrypt using a new passphrase.

• You have upgraded the encryption type with which new or updated passwords are stored, and you also want to upgrade the format of currently stored passwords.

• You want to downgrade the format of currently stored passwords.

CAUTION:

When you use the following instructions to introduce, change, or clear a passphrase, all passwords in login objects within the specified metadata server are affected.

Make sure you have a current backup before you set a passphrase.

Note: Other passphrases (for example, the passphrase for the SAS Web Server) are

distinct from the passphrases that are described in this topic and are not affected by these instructions.

Set or Change a Passphrase (SAS Deployment Manager)

To change a passphrase using the SAS Deployment Manager:

1. On the metadata server's host, navigate to your equivalent of

SAS-installation-

directory/SASDeploymentManager/9.4/

and launch sasdm.exe (Windows), sasdm.sh (UNIX), or sasdm.rexx (z/OS).

Windows Specifics

On Windows, log on as a Windows administrator of the current machine.

Operating Environment Information

On UNIX and z/OS, log on with the user ID that was used to perform the SAS installation.

2. In the SAS Deployment Manager, select the change passphrase task and log on as an unrestricted user.

3. Change the passphrase. For assistance with the user interface, see the Help within the application.

Set or Change a Passphrase (METADATA Procedure)

To use a passphrase as the encryption key for passwords that are stored in metadata:

200

Chapter 14 • Encryption Tasks

1. Verify that the metadata server is configured to store passwords in SAS004 or

SAS003 format. Passphrase keys are supported for only these formats.

Note: The format in which the metadata server stores passwords is controlled by the

STOREPASSWORDS="SAS00n" setting in your equivalent of

SAS/Config/

Lev1/SASMeta/MetadataServer/omaconfig.xml

. Changes to this file take effect when you restart the metadata server.

2. In a SAS session, connect to the metadata server as an unrestricted user and pause the server for administration as follows.

options

metaserver='machine.company.com'

metaport=8651

metauser='sasadm@saspw'

metapass='secret';

proc metaoperate

action=PAUSE

options='<Server STATE="ADMIN"/>';

run;

3. In the SAS session, set a passphrase as follows. proc metadata

in="<ChangePassPhrase>

<PassPhrase>My passphrase</PassPhrase>

</ChangePassPhrase>";

run;

The preceding code decrypts currently stored passwords and then re-encrypts them using the passphrase that you supply.

T I P

You can use the PWENCODE procedure to prepare an encrypted version of your passphrase, and supply the encrypted version of the passphrase in the preceding code.

4. To verify results, inspect the metadata server log. See “How Password Re-encryption

Activity Is Logged” on page 202

5. In the SAS session, resume the metadata server.

proc metaoperate

action=RESUME;

run;

To re-encrypt stored passwords using a new passphrase, follow the preceding instructions and supply the new passphrase in step 3 as follows: proc metadata

in="<ChangePassPhrase>

<PassPhrase>My new passphrase</PassPhrase>

</ChangePassPhrase>";

run;

To remove a passphrase (and use the default fixed key instead), follow the preceding instructions and submit a blank passphrase in step 3 as follows: proc metadata

in="<ChangePassPhrase>

</ChangePassPhrase>";

run;

How to Re-Encrypt Stored Passwords

201

If you must maintain a few stored passwords in SAS002 format, see

“Compatibility” on page 205

Downgrade Stored Passwords

To downgrade the encryption type of stored passwords:

1. Configure the metadata server to store any new or updated passwords in the downgraded format. a. Locate your equivalent of

SAS/Config/Lev1/SASMeta/

MetadataServer/omaconfig.xml

and open the file for edit.

T I P

It is a good practice to make a copy of the file before you modify it.

b. Set the following options:

•

STOREPASSWORDS="SAS002"

•

HashPasswords="MD5"

Note: The latter setting is within the

InternalAuthenticationPolicy

section of the omaconfig.xml file. It affects passwords in internal accounts.

For details, see “How to Change Internal Account Policies” on page 177 .

c. Restart the metadata server.

2. In a SAS session, connect to the metadata server as an unrestricted user and pause the server for administration as follows.

options

metaserver='machine.company.com'

metaport=8651

metauser='sasadm@saspw'

metapass='secret';

proc metaoperate

action=PAUSE

options='<Server STATE="ADMIN"/>';

run;

3. In your SAS session, set a blank pass phrase as follows: proc metadata

in="<ChangePassPhrase>

</ChangePassPhrase>";

run;

Notice that the

PassPhrase

element is empty. The preceding code decrypts stored passwords and then stores them in a downgraded format.

4. To verify results, inspect the metadata server log. See “How Password Re-encryption

Activity Is Logged” on page 202

5. Resume the metadata server as follows: proc metaoperate

action=RESUME;

run;

6. Update the password in each internal account as follows:

•

For a managed internal account, use the SAS Deployment Manager. See “Update a Managed Password” on page 35

202

Chapter 14 • Encryption Tasks

• For other internal accounts, use SAS Management Console. See “Reset an

Internal Password” in SAS Management Console: Guide to Users and

Permissions

How Password Re-encryption Activity Is Logged

As the passwords within each repository are converted, repository-level messages are written to the metadata server log. Here are some examples of the messages:

ChangePassPhrase: repository Id=A5KUG99E, Name=repos1, PauseState=ADMIN is being processed.

ChangePassPhrase: repository Id=A5KUG98E, Name=repos2 is not being processed because the

PauseState=OFFLINE must be ADMIN.

To log changes to individual objects, add the following content to the metadata server’s log4sas.xml file:

</logger>

</logger>

Here are some examples of the log messages:

Audit Public Object Type=Login Name=user2 ObjId=A5KUG99E.AQ000001 has been updated.

Audit Public Object Type=Login Name=user3 ObjId=A5KUG99E.AQ000002 has been updated.

Audit Public Object Type=Login Name=sasadm ObjId=A5KUG99E.AQ000003 has been updated.

Note: The log messages are written after the objects are committed to the repository.

Changes to SASPassword objects are not logged.

How to Change Encoding for Data in Motion for

IOM Servers

Automatic Configuration

When you install the metadata server, you select an encryption level (which traffic content is encrypted) and an encryption algorithm (how that traffic is encrypted). In

How to Change Encoding for Data in Motion for IOM Servers

203

order to connect to the metadata server, clients must conform to the metadata server’s encryption requirements.

Note: If the FIPS encryption algorithm was set during the initial deployment, and you

manually change the server encryption algorithm, you must also remove the -

encryptfips option from the following files:

• ObjectSpawner.bat (Windows) or ObjectSpawner.sh (UNIX)

• ConnectSpawner.bat (Windows) or ConnectSpawner.sh (UNIX)

For more information about the encryptfips option, see “ENCRYPTFIPS System

Option” in Encryption in SAS .

Instructions

If you need to change encryption settings for data in motion after installation is complete, use the following instructions.

1. Update server configuration files as follows: a. In the operating system that hosts the metadata server, navigate to your equivalent of

SAS/Config/Lev1/SASMeta/MetadataServer/

• To change the algorithm, add the NETENCRALG setting that you need to the sasv9_usermods.cfg file.

• To change the encryption level, copy the entire OBJECTSERVERPARMS line from the sasv9.cfg file into the sasv9_usermods.cfg file. Then edit the

CEL value in the usermods version of the file.

For example, to encrypt all traffic with AES, add these lines:

-netencralg "AES"

-objectserverparms "cel=everything {other-parameters}"

On z/OS, exclude the initial hyphens and add equal signs as follows: netencralg="AES" objectserverparms="cel=everything {other-parameters}" b. (Optional) If your deployment offers direct connections from clients to the OLAP server, make the same updates to that server's configuration file.

Note: The OLAP server's configuration file is in your equivalent of

SAS/Config/Lev1/SASApp/OLAPServer/

2. Update server metadata definitions as follows: a. In SAS Management Console, under Server Manager, select the metadata server's definition .

Note: To get to the server definition, you must expand the application server

node and the logical server node .

b. Right-click the first connection object , and select Properties. c. In the Connection dialog box, select the Options tab and click Advanced

Options. Adjust the settings as necessary.

d. In the Advanced Options dialog box, select the Encryption tab.

Repeat the preceding steps for each server that is launched by the object spawner

(the stored process server, the workspace server, and the pooled workspace server).

204

Chapter 14 • Encryption Tasks

3. Stop, restart, and validate the servers.

About NETENCRALG and CEL

On direct connections, encryption is governed by the server's invocation command. Here are details and some examples:

NETENCRALG (network encryption algorithm) is a SAS system option. The NETENCRALG setting that is defined for the metadata server during installation is in the metadata server's sasv9.cfg file.

• If you accept the default encryption settings during installation, the configuration file includes this line:

-netencralg "SASProprietary"

• If you selected the AES algorithm during installation, the setting in the metadata server's sasv9.cfg file is as follows:

-netencralg "AES"

• If a different NETENCRALG setting has been added to the metadata server's sasv9_usermods.cfg file, that setting has priority.

• Other supported values for NETENCRALG are DES, TripleDES, RC4, and RC2.

CEL (client encryption level) is a parameter in the OBJECTSERVERPARMS SAS system option. The CEL setting that is defined for the metadata server during installation is in the metadata server's sasv9.cfg file.

• If you accept the default encryption settings during installation, the configuration file includes this line:

-objectserverparms "cel=credentials {other-parameters}"

• If, during installation, you selected the option to encrypt all traffic, the setting in the metadata server's sasv9.cfg file is as follows:

-objectserverparms "cel=everything {other-parameters}"

• If a different CEL setting has been added to the metadata server's sasv9_usermods.cfg file, that setting has priority.

Note: On z/OS, the preceding syntax examples are slightly different. See step 1a in the

preceding topic.

It is not necessary to specify encryption settings in the invocation command for every component for the following reasons:

• Encryption algorithm and level are negotiated between each pair of communicating components. For example, when the OLAP server and object spawner initialize, they contact the metadata server and conform to the metadata server's encryption settings.

The same negotiation occurs when a client application contacts a server.

• For spawned servers (the stored process server, the pooled workspace server, and the workspace server), encryption is determined by metadata settings, not by a server invocation command.

How to Change Encoding for Data in Motion for

Outbound Passwords

A password is outbound when a client retrieves the password from the metadata in order to provide seamless access to a server such as Oracle. The password is outbound from the perspective of the metadata server. Connections to third-party servers often use outbound passwords. Most other connections do not use outbound passwords.

Instructions

In the initial configuration, outbound passwords are transmitted in SAS002 format

(SASProprietary).You can choose to increase the encoding strength for outbound passwords to AES 256 with 16-bit salt (SAS003) or AES 256 with 64-bit salt (SAS004).

To increase encryption strength for outbound passwords:

1. Edit the metadata server's omaconfig.xml file to change the initial setting,

RETURNPASSWORDS="SAS002", to a more secure setting (for example,

RETURNPASSWORDS="SAS004"). The metadata server's omaconfig.xml file is located in your equivalent of

SAS/Config/Lev1/SASMeta/

MetadataServer/

Note: For more information, see the RETURNPASSWORDS option in

“Reference

Information for omaconfig.xml” in SAS Intelligence Platform: System

Administration Guide

2. Restart the metadata server.

3. Verify that server connections continue to function as expected. If you encounter problems, either review the following topic or revert to

RETURNPASSWORDS="SAS002".

Compatibility

Almost all connections involve a SAS server, and SAS servers can decode SAS004 passwords. For example, connections from SAS Information Map Studio to an Oracle server go through a workspace server. The workspace server decodes the outbound

Oracle password.

However, a few specialized connections run directly from a Java client or .NET client to a third-party server. These clients cannot decode SAS003 and SAS004 passwords. This is a deliberate limitation that reduces security exposures. Of course, a third-party server cannot decode SAS003 and SAS004 passwords either. As a result, such connections fail if they attempt to use a password that is in either of those formats. Here are some examples of connections that cannot use a SAS003 or SAS004 password:

• Connections from a Java client or .NET client to an Esri server.

Note: The Esri server uses host authentication. If possible, avoid the use of

outbound passwords by locating this server on a machine that recognizes the

206

Chapter 14 • Encryption Tasks

accounts with which users log on to SAS applications. This facilitates use of cached credentials to access the Esri server.

• Certain connections within the following solutions:

• SAS Profitability Management

• SAS Activity-Based Management

• SAS Merchandise Intelligence

• SAS Model Manager (in some configurations)

• SAS LASR Analytic Server

• Internal database management system (DBMS) accounts (for example, the administrator of the SAS Web Infrastructure Platform Data Server, dbmsowner).

If your deployment requires connections that are incompatible with SAS003 or SAS004 passwords, choose either of the following approaches:

• Preserve the initial setting of RETURNPASSWORDS="SAS002".

Note: With the STOREPASSWORDS="SAS003" and

RETURNPASSWORDS="SAS002" settings, outbound passwords are stored in

SAS003 format and downgraded to SAS002 format before they are transmitted.

• Set RETURNPASSWORDS="SAS003", but also selectively force the outbound passwords for the problematic connections to be transmitted in SAS002 format. To force a particular password to be transmitted in SAS002 format, store that password in that format. A password that is stored in SAS002 format is transmitted in that format even if RETURNPASSWORDS="SAS003", because the metadata server does not upgrade the encoding strength of a stored password when the password is transmitted.

To use this approach:

1. In the metadata server's omaconfig.xml file, set

STOREPASSWORDS="SAS002". Restart the metadata server.

2. In SAS Management Console, under User Manager, locate and select the login that contains the outbound password. The login is on the Accounts tab of a user or group definition.

3. Click Edit. In the Login Properties dialog box, enter and confirm the password.

Click OK to close the Login Properties dialog box. Click OK again to close the user or group properties dialog box.

Note: This stores the password in the metadata in SAS002 format.

4. Repeat steps 2 and 3 for any other problematic outbound passwords.

5. In the metadata server's omaconfig.xml file, upgrade the settings (for example, set STOREPASSWORDS="SAS004" and RETURNPASSWORDS="SAS004").

Restart the metadata server.

6. Verify that server connections continue to function as expected.

Note: Anytime in the future that you update the SAS002 passwords, you must repeat

the preceding steps process in order to store the new password in SAS002 format.

How to Configure TLS between the Metadata Server and an LDAP Server

207

How to Configure TLS between the Metadata

Server and an LDAP Server

Before You Begin

This is not a universally necessary task. The following instructions support encryption of direct communication between the metadata server and an LDAP server using the

Transport Layer Security (TLS) protocol. This content is also applicable to the predecessor protocol, Secure Sockets Layer (SSL).

This functionality applies to only specialized configurations in which the metadata

server directly uses an LDAP server as an authentication provider. See “Direct LDAP

Authentication” on page 136

Configuration Instructions

1. On the LDAP server: a. Make sure that a port is configured for TLS. b. Examine the Client Certification setting and note its implications for your work in step 2e below.

• If the setting specifies that a client certificate is optional, step 2e below is optional for you. This is the default setting on most LDAP servers.

• If the setting specifies that a client certificate is required, step 2e below is mandatory for you.

• If the setting specifies that a client certificate is not allowed, a client certificate is ignored, so there is no reason for you to perform step 2e below.

2. On the metadata server: a. If support is not already in place for direct LDAP, configure that support. See

“How to Configure Direct LDAP Authentication” on page 160

b. Make sure that the value that is specified in the LDAP_PORT (or AD_PORT) environment variable matches a TLS-configured port on the LDAP server. c. In the same location where you set environment variables to configure the metadata server for direct LDAP, add the LDAP_TLSMODE (or

AD_TLSMODE) environment variable, and set it to

. Setting this variable causes the metadata server to attempt to use TLS.

d. Provide a certificate authority (CA) certificate to use TLS.

Host

Windows

Details

The CA certificate is installed using Microsoft Certificate Services.

208

Chapter 14 • Encryption Tasks

Host

UNIX z/OS

Details

For the second maintenance release of SAS 9.4 and previous releases, the CA certificate file is provided in an accessible directory and referenced by the SSLCALISTLOC option.

In the third maintenance release of SAS 9.4, certificates are located in the trusted CA bundle (trustedcerts.pem) by default, and the

SSLCALISTLOC system option that points to this certificate file is automatically added at installation to the sasv9.cfg file. The sasv9.cfg file is located in

SAS-installation-directory/

SASFoundation/9.4

. For more information, see SAS 9.4

Intelligence Platform: Installation and Configuration Guide.

The CA certificate file is provided in an accessible directory and referenced by the SSLCALISTLOC option.

Add the option to the metadata server's invocation command (in the same location where you specified -authpd). For syntax, see "SAS System Options for Encryption" in Encryption in SAS.

e. If the LDAP server requires client certification (see step 1b above), specify the location of client certificates.

Host

Windows

UNIX z/OS

Details

The client certificate is installed using Microsoft Certificate

Services. The SSLCERTSUBJ, SSLCERTSERIAL, and

SSLCERTISS options are used to locate the client certificate.

The client certificate files are provided in an accessible directory.

The SSLCERTLOC, SSLPVTKEYLOC, and SSLPVTKEYPASS options can be used to locate the client certificate. PKCS12 certificates can also be used with the SSLPKCS12LOC and

SSLPKCS12PASS options.

The client certificate files are provided in an accessible directory.

The SSLCERTLOC, SSLPVTKEYLOC, and SSLPVTKEYPASS options can be used to locate the client certificate. PKCS12 certificates can also be used with the SSLPKCS12LOC and

SSLPKCS12PASS options.

Add the necessary options to the metadata server's invocation command (in the same location where you specified -authpd). For syntax, see "SAS System Options for Encryption" in

Encryption in SAS.

3. Restart the metadata server.

4. To test the results, use the following code. Replace the sample values with your metadata server connection information, and submit the code in a SAS code editor.

proc metaoperate

server="a123.us.company.com"

port=8561

userid="myLDAPuserID@myldap"

password="myLDAPpassword"

action=status; run;

How to Configure TLS between the Metadata Server and an LDAP Server

209

Connecting to an LDAP Load Balancer

Potential Problem

In the default TLS configuration, each connection includes a server name check to verify that the host name in the certificate of the node to which the metadata server connected matches the host name of the target LDAP server.

If the connection is to an LDAP server load balancer (rather than directly to the authenticating LDAP server), the server name check might fail, because the LDAP load balancer might be on a different node than the LDAP server to which the metadata server is redirected.

Preferred Solution: Wildcard Certificate

If you encounter the problem that is described in the preceding section, use a wildcard when specifying the subject name in the certificate.

For example, instead of specifying

myHost.myCompany.com

, specify

*.myCompany.com

CAUTION:

If you use a wildcard, only the domain portion of the server name in the certificate is validated against the server that you connect to.

Do not use this approach unless you encounter the problem that is described in the preceding section.

Note: Using a wildcard is the preferred solution because it provides domain name

validation, which reduces the risk of Domain Name System (DNS) redirection or hijacking.

Alternate Solution: Environment Variable

As an alternative to using a wildcard certificate, you can disable the server name check by defining an additional environment variable (NOSSLNAMECHECK=1) for the metadata server. For example, you might add the following setting to the sasv9.cfg file:

-set NOSSLNAMECHECK 1

Or, you can define the environment variable in the metadata server’s start-up script as follows: export NOSSLNAMECHECK=1

CAUTION:

In this approach, neither the server name nor the domain name is validated.

For this reason, using a wildcard certificate is the preferred solution to the problem that is described in the preceding section.

SASSSLREQCERT

Windows Specifics

Windows clients always request and verify server certificates. The

SASSSLREQCERT environment variable is supported only on UNIX.

The SASSSLREQCERT environment variable specifies what checks to perform on server certificates in a TLS session. This environment variable supports the following settings:

210

Chapter 14 • Encryption Tasks

DEMAND

A server certificate is requested. If no valid certificate is provided, the session terminates. DEMAND is the default setting.

TRY

The client requests a server certificate. If no certificate is provided, the session proceeds normally. If an invalid certificate is provided, the session terminates.

ALLOW

The client requests a server certificate, but the session proceeds normally even if no certificate is provided or an invalid certificate is provided.

NEVER

The client does not request a server certificate.

For example, add the follow setting to the script: export SASSSLREQCERT=ALLOW

How to Implement Certificates

Obtaining a Signed Certificate for SAS Web Server

If you have not used certificates in the past, you might want to obtain a site-signed or third-party-signed certificate. Although each SAS machine needs its own private key and server certificate, you can generate the private key and a certificate signing request

(CSR) on any machine. The most important thing is to safeguard the private key. This topic provides you with an overview of how to obtain a signed certificate for SAS Web

Server.

Unlike the other SAS middle-tier components that require their certificates in a Java keystore, SAS Web Server requires two files:

• private key

This private key is in RSA format, is not protected with a passphrase, and is saved in

ASCII (Base64-encoded) PEM format.

• CA-signed certificate

This certificate contains the server’s public key in X.509 certificate form and is saved in ASCII (Base64-encoded) PEM format.

This topic explains how to obtain a signed certificate for SAS Web Server on UNIX. For steps on Windows, see “TLS on Windows: Setting Up Digital Certificates ” in

Encryption in SAS

. To obtain a site-signed or third-party-signed certificate for SAS Web

Server, perform these steps:

1. Decide which type of CA to use at your site:

• site-signed

• third-party-signed

How to Implement Certificates

211

2. Establish a location on your machine where you will store your private key and signed certificates.

For the examples in this document,

/opt/certs

is used to store the private key and certificates.

3. Change the directory to where your

openssl

commands reside.

For example:

cd /usr/bin

4. Use the

openssl

command to create a private key.

For example:

./openssl genrsa -out /opt/certs/machine01_key.pem 2048

T I P

For more information about

openssl

commands, see https:// www.openssl.org/docs/manmaster/apps/openssl.html

5. Use the

openssl

command to create a CSR.

For example:

./openssl req -new -key /opt/certs/machine01_key.pem out /opt/certs/machine01_csr.pem

6. Submit your CSR file and your private key to your CA.

You should receive the following from your CA:

• signed certificate (containing the CA’s public key)

• CA root certificate

• CA intermediate certificate

7. Store the private key and certificates that you received from your CA in the location

that you established in Step 2

For more information, go to the link appropriate for your operating system.

• On Windows, see “TLS on Windows: Setting Up Digital Certificates ” in Encryption

in SAS

• On UNIX, see “ Setting Up Digital Certificates Using OpenSSL ” in Encryption in

SAS

• On z/OS, see “TLS on z/OS: Setting Up Digital Certificates” in Encryption in SAS .

Obtaining a Signed Certificate for Middle-Tier Components

If you have not used certificates in the past, you might want to obtain a site-signed or third-party-signed certificate. This topic provides you with an overview of how to obtain a signed certificate for a SAS middle-tier component (other than SAS Web Server).

Unlike SAS Web Server, SAS Web Application Server, SAS Environment Manager, and

SAS Deployment Agent require their certificates in a Java keystore.

Note: For commands to obtain signed certificates for SAS Web Server, see

“Obtaining a

Signed Certificate for SAS Web Server” on page 210 .

To obtain a site-signed or third-party-signed certificate for SAS middle-tier components

(other than SAS Web Server), perform these steps:

1. Decide which type of CA to use at your site:

212

Chapter 14 • Encryption Tasks

• site-signed

• third-party-signed

2. Establish a location on your machine where you will store your private key and signed certificates.

For the examples in this document,

/opt/certs

is used to store the private key and certificates.

T I P

If any SAS middle-tier component resides on the same machine as SAS

Environment Manager, we recommend that you use the path and password that

SAS Environment Manager uses by default (for example,

../../config/ hyperic.keystore

for Hyperic). By doing so, you will not have to manually specify a new path and password later in the configuration.

3. Change the directory to where your

keytool

command resides.

For example:

cd /usr/java/jdk1.8.0_45/bin

4. Use the

keytool

command to create a keystore. (By default, a keystore contains a private key.)

For example:

./keytool -genkey -alias hq -keyalg RSA -keystore /opt/ certs/hyperic.keystore -keysize 2048

T I P

For more information about the

keytool

command, see http:// docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html

5. Use the

keytool

command to create a CSR.

For example:

./keytool -certreq -alias hq -keystore /opt/certs/ hyperic.keystore -file /opt/certs/hyperic.csr

6. Submit your CSR file and your private key to your CA.

You should receive the following from your CA:

• signed certificate (containing the CA’s public key)

• CA root certificate

• CA intermediate certificate

7. Store the private key and certificates that you received from your CA in the location

that you established in Step 2

8. Use the

keytool

command to add the CA root certificate, CA intermediate certificate, and the signed certificate (in this order) to your keystore.

a. Add the CA root certificate to your keystore.

In this example, root_ca.cer is the CA root certificate and hyperic.keystore is the keystore file:

./keytool -importcert -file /opt/certs/root_ca.cer keystore /opt/certs/hyperic.keystore -trustcacerts -alias rootca

b. Add the CA intermediate certificate to your keystore.

In this example, int_ca.cer is the CA intermediate certificate:

How to Implement Certificates

213

./keytool -importcert -file /opt/certs/int_ca.cer keystore /opt/certs/hyperic.keystore -trustcacerts -alias intca

c. Add the signed certificate to your keystore.

In this example, myserver_signed.cer is the signed certificate:

./keytool -importcert -file /opt/certs/ myserver_signed.cer -keystore /opt/certs/hyperic.keystore

-trustcacerts -alias myserver

9. Verify that the certificates that you added to your keystore are present:

./keytool -list –keystore path-to-keystore-file

In this example, hyperic.keystore is the keystore file:

You should see something similar to the following (look for the aliases that you added):

Keystore type: JKS

Keystore provider: SUN

Your keystore contains 4 entries myserver, Oct 16, 2015, trustedCertEntry,

Certificate fingerprint (SHA1): DA:62:4A:D6:14:79:28:46:0C:45:1D:1B:F8:

5C:29:BE:69:79:9D:2E intca, Oct 16, 2015, trustedCertEntry,

Certificate fingerprint (SHA1): 12:4D:C9:88:CD:D5:F3:E9:9E:29:D8:AB:F1:

00:AD:93:60:61:11:45 hq, Oct 16, 2015, PrivateKeyEntry,

Certificate fingerprint (SHA1): BD:9C:D3:C1:61:D1:0C:93:5D:4F:6D:49:77:

B1:40:C2:60:96:67:C3 rootca, Oct 16, 2015, trustedCertEntry,

Certificate fingerprint (SHA1): 16:E4:1E:AC:F0:0C:1E:DB:30:3A:1A:C3:EF:

4C:D6:D5:15:38:2A:25

For more information, go to the link appropriate for your operating system.

• On Windows, see “TLS on Windows: Setting Up Digital Certificates ” in Encryption

in SAS

• On UNIX, see “ Setting Up Digital Certificates Using OpenSSL ” in Encryption in

SAS

• On z/OS, see “TLS on z/OS: Setting Up Digital Certificates” in Encryption in SAS .

Implementing Certificates

The following list summarizes the steps to implement the various certificate options:

• Using self-signed certificates automatically generated by SAS Deployment Wizard.

For more information, see “Using Auto-Generated Certificates” .

This option consists of installing and configuring the SAS middle tier using the deployment wizard.

•

Providing your own certificates. For more information, see “Providing Your Own

Certificates” .

214

Chapter 14 • Encryption Tasks

This option consists of these high-level steps:

1. If you do not already have them, obtain your certificates and private keys. Store these certificates and private keys on any machine that has the SAS components that use them.

2. Install and configure your SAS metadata tier and SAS server tier.

(Use SAS Deployment Wizard.)

Note: When prompted, use the auto-generated certificates for SAS Deployment

Agent and its remote client. Later, you can replace the auto-generated certificates with certificates that you provide.

3. On both Windows and UNIX on the SAS metadata-tier and SAS server-tier machines, depending on your release of SAS 9.4, add your CA root certificate and intermediate certificates either to the trusted CA bundle or to the SAS Private

JRE.

(Use SAS Deployment Manager or the Java

keytool -importcert

command.)

4. On Windows on the SAS metadata-tier and SAS-server tier machines, you must also add your CA root certificate and intermediate certificates to the Windows certificates store using the Windows Certificates Snap-in. (Most third-partysigned CA certificates already exist in the Windows certificates store.)

5. Install your SAS middle tier.

(Use SAS Deployment Wizard.)

6. On both Windows and UNIX middle-tier machines, add your certificates to the trusted CA bundle.

(Use SAS Deployment Manager.)

7. On Windows middle-tier machines, you must also add any pre-existing selfsigned and site-signed certificates to the Windows certificates stores using the

Windows Certificates Snap-in. (Most third-party-signed CA certificates already exist in the Windows certificates stores.)

8. Configure your SAS middle tier.

(Use SAS Deployment Wizard.)

9. Perform manual, post-deployment steps.

Note: Implementing certificates for SAS Web Application Server consists of

manual, post-deployment steps.

• Using a combination of self-signed certificates automatically generated and providing your own certificates.For more information, see

“Using a Combination of

Auto-Generated and Your Own Certificates” .

This option has the same steps as providing your own certificates. The only difference is that you do not replace the auto-generated certificates with your own certificates.

Using Auto-Generated Certificates

If you want SAS Deployment Wizard to generate self-signed certificates to secure SAS

Deployment Agent and its remote client and the SAS Environment Manager server and its agents, perform these steps:

How to Implement Certificates

215

Note: Using auto-generated certificates secures your SAS Deployment Agent and SAS

Environment Manager only. To secure all of the components in your SAS middle tier, you must provide your own certificates or use a combination of your own certificates and certificates auto-generated by SAS Deployment Wizard. For more

information, see “Implementing Certificates” on page 195 .

1. Run SAS Deployment Wizard. Make sure that both Install SAS Software and

Configure SAS Software are selected.

2. When you are prompted for the SAS Deployment Agent remote communication configuration, select Generate credentials to secure the connection.

3. When you are prompted for the configuration prompting level, select Custom.

4. When you are prompted, make sure that you select Generate a default JKS format

keystore from SAS Environment Manager.

5. When you are prompted, make sure that you select Establish secure

communication.

Providing Your Own Certificates

For SAS Deployment Agent and its remote client and for the SAS Environment Manager server and its agents, SAS Deployment Wizard provides auto-generated, self-signed certificates by default. Because these certificates have intermachine connections, are behind your firewall, and do not involve users, there is less of a reason to implement site-signed or third-party-signed certificates. However, if you must use your own certificates, you can.

This topic explains how to accept the default action—that is, let SAS Deployment

Wizard install auto-generated self-signed certificates for you. After the deployment wizard is finished, you can go back and replace the auto-generated, self-signed certificates with certificates that you provide, which saves you several manual configuration steps.

To provide your own certificates to secure your SAS middle tier, follow these steps:

1. If you do not already have them, obtain your certificates. For more information, see

“Obtaining Certificates” on page 192

2. Decide on a location on each machine in your SAS environment where you will store your certificates. Make sure that your certificates reside in these locations.

3. Use the following table to record keystore and truststore locations and passwords for

SAS Deployment Agent and its remote client.

SAS Deployment Wizard prompts you for these locations and passwords during SAS installation and configuration. The deployment wizard encodes the passwords that you provide into SAS proprietary format (SAS002).

Note: Your keystore must be in JKS format.

T I P

We recommend that instead of providing your own certificates to SAS

Deployment Agent during installation, that you accept the default and let SAS

Deployment Wizard install auto-generated self-signed certificates for you. After the deployment wizard is finished, you can go back and replace the autogenerated, self-signed certificates with certificates that you provide, which saves you several manual configuration steps.

216

Chapter 14 • Encryption Tasks

Table 14.1 SAS Deployment Agent Keystore and Truststore Information

Keystore and Truststore

Properties Actual Value You Are Using

SAS Deployment Agent keystore path

SAS Deployment Agent keystore password

SAS Deployment Agent truststore path

SAS Deployment Agent truststore password

SAS Deployment Agent remote client keystore path

SAS Deployment Agent remote client keystore password

SAS Deployment Agent remote client truststore path

SAS Deployment Agent remote client truststore password

4. Use the following table to record keystore locations and passwords for the SAS

Environment Manager server and its agents.

Table 14.2 SAS Environment Manager Keystore Information

Keystore Properties

SAS Environment Manager server keystore path

Actual Value You Are Using

SAS Environment Manager server keystore password

SAS Environment Manager alias

SAS Environment Manager agent keystore path

How to Implement Certificates

217

Keystore Properties

SAS Environment Manager agent keystore password

Actual Value You Are Using

5. Use the following table to record certificate and private key locations for SAS Web

Server. SAS Deployment Wizard prompts you for these locations and passwords during SAS installation and configuration.

Table 14.3 SAS Web Server Private Key and Certificate Information

Private Key and

Certificate Properties

SAS Web Server X.509 certificate path

SAS Web Server RSA private key path

Actual Value You Are Using

6. Use the following table to record keystore locations and passwords for SAS Web

Application Server and its agents. SAS Deployment Wizard does not prompt you for these locations and passwords. You must manually update the SAS Web Application

Server configuration with this information after you deploy SAS.

T I P

You can use the same keystore for SAS Environment Manager and SAS Web

Application Server if they reside on the same machine.

Table 14.4 SAS Web Application Server Keystore Information

Actual Value You Are Using Keystore Properties

SAS Web Application

Server keystore path

SAS Web Application

Server keystore password

7. Install and configure your SAS metadata-tier and SAS-server tier machines. For more information, see

“Using Auto-Generated Certificates” on page 214

8. Add your CA root certificate and intermediate certificates to your SAS metadata-tier and SAS server-tier machines. For more information, see “Overview of Certificate

Management Using the SAS Deployment Manager” in Encryption in SAS .

9. On each of your middle-tier machines, start SAS Deployment Wizard by navigating to

SAS-installation-directory/SASDeploymentManager/9.4

, and launch

setup.exe

(Windows) or

setup.sh

(UNIX). On Windows, you can use the shortcut on the Start menu.

10. On the Select Deployment Type page, select Perform a Planned Deployment and

Install SAS Software.

Note: Make sure that Configure SAS Software is deselected.

218

Chapter 14 • Encryption Tasks

11. When prompted by the deployment wizard, select Generate credentials to secure

the connection, and click Next.

T I P

We recommend that instead of providing your own certificates to SAS

Deployment Agent during installation, that you accept the default and let SAS

Deployment Wizard install auto-generated self-signed certificates for you. After the deployment wizard is finished, you can go back and replace the default SAS

Environment Manager auto-generated JKS keystore with certificates that you provide. Choosing Generate credentials to secure the connection saves you several manual configuration steps.

12. On the Additional Resources page, click Finish to close the deployment wizard.

13. If you have additional middle-tier machines, repeat steps 4 through 9 on each middle-tier machine.

Otherwise, proceed to the next step.

14. Perform one of the following steps based on your operating system:

• Windows

• Depending on your release of SAS 9.4, add your CA root certificate and intermediate certificates either to the trusted CA bundle or to the SAS Private

JRE on each of your middle-tier machines. For more information, see “Add

Your Certificates to the Trusted CA Bundle” in Encryption in SAS or “Add

Your Certificates to the SAS Private JRE” in Encryption in SAS .

• Using the Windows Certificates Snap-in, add your CA root certificate and intermediate certificates to the Windows certificates stores on each of your middle-tier machines. For more information, see “Add Your Certificates to the Windows CA Stores” in Encryption in SAS .

• UNIX:

Depending on your release of SAS 9.4, add your CA root certificate and intermediate certificates either to the trusted CA bundle or to the SAS Private

JRE on each of your middle-tier machines.

For more information, see “Add Your Certificates to the Trusted CA Bundle” in

Encryption in SAS

or “Add Your Certificates to the SAS Private JRE” in

Encryption in SAS

15. On each of your middle-tier machines, start SAS Deployment Wizard by navigating to

SAS-installation-directory/SASDeploymentManager/9.4

, and launch

setup.exe

(Windows) or

setup.sh

(UNIX). On Windows, you can use the shortcut on the Start menu.

16. On the Select Deployment Type page, select Perform a Planned Deployment and

Configure SAS Software.

Note: Make sure that Install SAS Software is deselected.

17. When prompted for the configuration prompting level, select Custom.

18. On the SAS Web Server Configuration page, select HTTP Protocol using Secure

Sockets, and click Next.

19. The deployment wizard prompts you for the following information. Enter the values

that you recorded earlier in Table 14.3

, and click Next:

• In the X.509 certificate field, enter the path to the X.509 certificate with the DNS name of the current machine as the common name.

How to Enable IOM Communication over HTTPS Proxy

219

• In the RSA private key field, enter the path to the RSA private key that is not protected by a passphrase.

Note: SAS Web Server does not use a passphrase so that it can start without

having to prompt the administrator for a passphrase.

20. When prompted by the deployment wizard, select Generate a default JKS format

keystore from SAS Environment Manager, and click Next.

T I P

We recommend that instead of providing your own certificates to SAS

Environment Manager during installation, that you accept the default and let SAS

Deployment Wizard install auto-generated self-signed certificates for you. After the deployment wizard is finished, you can go back and replace the default SAS

Environment Manager auto-generated JKS keystore with certificates that you provide. Choosing Generate a default JKS format keystore from SAS

Environment Manager saves you several manual configuration steps.

Using a Combination of Auto-Generated and Your Own Certificates

SAS Web Server and the SAS Web Application Server—you provide your own certificates.

The steps for using a combination of certificates are almost identical to the steps performed when you provide your own certificates, except that you replace the auto-

generated certificates with your own certificates. For more information, see “Providing

Your Own Certificates”

How to Enable IOM Communication over HTTPS

Proxy

Introduction

Starting with the third maintenance release of SAS 9.4, you can configure Integrated

Object Model (IOM) communication over HTTPS. You can update a SAS Web Server to act as a HTTPS proxy, allowing secured IOM communications between applications and back end IOM Servers, such as SAS Metadata Server or SAS Workspace Server.

Prior to configuring the proxy, SAS Web Server must be configured for TLS. If you did not choose to configure with secure sockets during the initial installation and configuration with SAS Deployment Wizard, you can manually configure SAS Web

Server to use HTTPS. For more information, see “Configuring SAS Web Server

Manually for HTTPS” in SAS Intelligence Platform: Middle-Tier Administration Guide .

Configuring the HTTPS Proxy

Starting with the fourth maintenance of SAS 9.4, the HTTP component that is shipped by SAS can be configured as an HTTPS proxy. Prior to the fourth maintenance of SAS

220

Chapter 14 • Encryption Tasks

9.4, customers who want to configure an HTTPS proxy need to perform the following steps to update specific httpd components and configuration files:

1. An updated version of mod_proxy_connect is required for SAS Web Server to act as a HTTPS proxy. This update is available from SAS Technical Support. After you receive the update, complete the following: a. Backup the mod_proxy_connect module.

b. Copy the mod_proxy_connect module from SAS Technical Support to the

SASHome\SASWebServer\9.4\httpd-2.2.31.1-64/modules

directory, replacing the existing module if it is in the directory.

Note: Your version of httpd may differ, based on your release of SAS 9.4.

c. Edit the

SAS-configuration-directory\Levn\Web\WebServer\conf

\httpd.conf

file to load the new mod_proxy_connect, by specifying the following:

LoadModule proxy_connect_module

“path/mod_proxy_connect.so”

Note: If SAS Web Server was already loading the module, the statement may

already be defined in the httpd.conf file.

2. Edit the

SAS-configuration-directory\Levn\Web\WebServer\conf

\sas.conf

file and specify which ports the proxy server should allow to connect to the back end by including the following information:

ProxyRequests On

ProxyVia On

# Below should include ports to be proxied, for example, 8561 for the metadata server.

AllowCONNECT 8561 8591

Order allow,deny

Allow from all

</Proxy>

Note: The comment must be on one line. It is shown on more than one line in the

preceding code sample for display purposes only.

3. Restart the SAS Web Server by running the following command:

SAS-configuration-directory\Levn\Web\WebServer\bin\httpdctl restart

4. Set the proxy list for your client. Proceed to either

“Connecting to an IOM Server

Via Proxy While Using an Environment Variable” on page 221 or “Registering

Proxy Information in SAS Metadata Server For Other Servers” on page 221

CAUTION:

Do not use both methods to set the proxy list for your client.

If the environment variable is used and the proxy information stored in metadata, some clients may see this as multiple proxies. It is possible to go through multiple proxies to reach the back end IOM server, therefore configuring both methods may cause the client to attempt to go through the same proxy twice. If the proxy allows connections to itself, this will result in an inefficient trip back through the same proxy. However, if the proxy does not allow connections to itself, this could result in a connection error.

How to Enable IOM Communication over HTTPS Proxy

221

Connecting to an IOM Server Via Proxy While Using an Environment

Variable

Now that the proxy is configured, clients must be directed to use the proxy to communicate with the IOM Server. In the following procedure, we use SAS Metadata

Server and SAS Management Console. An environment variable can be used to force the client application to go through a proxy when making the outgoing connection.

1. The client application’s IOM server connection information should not be changed.

It should appear to continue to connect to the same host and port that the server itself is running on. If the SAS Metadata server is running on

myMetadataServer.mydomain.com on port 8561, then the connection information in

SAS Management Console should be the same:

• Machine: myMetadataServer.mydomain.com

• Port: 8561

2. Configure SAS Management Console to connect through the proxy https://

myproxy.mydomain.com by setting the SAS_IOM_PROXYLIST environment

variable.

Set the variable before SAS Management Console is started. The value of this variable is a semicolon separated list of one or more proxies that the client application must go through before connecting to SAS Metadata Server. The variable is similar to the following:

SAS_IOM_PROXYLIST = https://myproxy.mydomain.com

After this variable is set, all connections to IOM servers from this host will go through the proxy at https://myproxy.mydomain.com. A tunnel through this proxy will be created to communicate with the back end server. In the case of our example, that would be SAS

Metadata Server.

Registering Proxy Information in SAS Metadata Server For Other

Servers

It is also possible to store proxy information in SAS Metadata Server. Applications that find server definitions in SAS Metadata Server, such as the SAS Workspace Server, will use the proxy information stored with the server definition to make a connection through the proxy to the server endpoint.

In SAS Metadata Server, individual machines are configured to use proxies using a proxy list object. Machines are registered in the proxy list object and are mapped to a list of proxies. Any client that is making a connection to the registered machines of the proxy list should find the list of proxies and make connections through these proxies to the machine registered.

To configure the proxy list in SAS Metadata Server, follow these steps.

1. Log on to SAS Management Console as an administrator.

2. On the Plug-ins tab, navigate to Environment Management

Server Manager.

3. Right-click Server Manager, and select New Server.

4. In the New Server Wizard dialog, navigate to and select the Proxy List entry, and then click Next.

222

Chapter 14 • Encryption Tasks

5. Provide a name for the proxy list object and click Next. The name that you specify is for reference only.

6. To add a proxy to the list, click New under the Proxies section. Enter the proxy URI, and then click OK.

7. Repeat step 6 to add all of the proxies. The proxy list is ordered, and applications will enforce the order of the proxies as they appear in this list.

8. After the proxies are added, select the machines to register with the Proxy List. In the

Proxied Machines section, move one or more machines from the Available list to the Selected list. Click Next to continue.

9. A summary of the details about the Proxy List object that will be created is displayed. Click Finish.

After the proxy list is defined in metadata, any connection that is going to an IOM

Server on the defined server (for example, myServer.mydomain.com) will go through the https://myproxy.mydomain.com proxy first.

223