ameblo.over-update.download

• Ssrs Product Key

All environments of Common Data Service use SQL Server Transparent Data Encryption (TDE) to perform real-time encryption of data when written to disk, also known as encryption at rest.

SSRS Encryption Keys - Back Up and Restore Encryption Keys.; 4 minutes to read +2; In this article. APPLIES TO: SQL Server 2016 and later Azure SQL Database Azure Synapse Analytics (SQL DW) Parallel Data Warehouse An important part of report server configuration is creating a backup copy of the symmetric key used for encrypting sensitive information. Change the SQL Server Reporting Services Service Account. Once the Encryption Key Backup is created successfully, the next step is to change the Service Account. Windows default key generation algorithm calg md5. In the Reporting Services Configuration Manager, click on Service Account as shown below. Enter the new Service Account and Password and then press the Apply button. As soon as you.

By default, Microsoft stores and manages the database encryption key for your environments so you don't have to. The manage keys feature in the Power Platform admin center gives administrators the ability to self-manage the database encryption key that is associated with the Common Data Service tenant.

Important

Self-managed database encryption keys are only available for customers who have more than 1000 Power Apps plan and/or Dynamics 365 plan licensed user seats and who have opted in to the feature. To opt in to this program, contact your account or sales representative.

Encryption key management is only applicable to Azure SQL environment databases. The following features and services use their own key to encrypt their data and can't be encrypted with the self-managed encryption key:

• Relevance Search
• Mobile Offline
• Activity Log (Office 365 portal)
• Exchange (Server-side sync)

Encryption key management cannot be applied to environments that have data stored in File and Image fields.

A majority of existing environments have file and log stored in non-Azure SQL databases. These environments cannot be opted in to self-managed encryption key. Only new environments (once you signed up for this program) can be enabled with self-managed encryption key.

Introduction to key management

With key management, administrators can provide their own encryption key or have an encryption key generated for them, which is used to protect the database for an environment.

The key management feature supports both PFX and BYOK encryption key files, such as those stored in a hardware security module (HSM). To use the upload encryption key option you need both the public and private encryption key.

The key management feature takes the complexity out of encryption key management by using Azure Key Vault to securely store encryption keys. Azure Key Vault helps safeguard cryptographic keys and secrets used by cloud applications and services. The key management feature doesn't require that you have an Azure Key Vault subscription and for most situations there is no need to access encryption keys used for Common Data Service within the vault.

The manage keys feature lets you perform the following tasks.

• Enable the ability to self-manage database encryption keys that are associated with Common Data Service environments.

• Generate new encryption keys or upload existing .PFX or .BYOK encryption key files.

• Lock and unlock tenant environments.

  Warning

  While a tenant is locked, all environments within the tenant can't be accessed by anyone. More information: Lock the tenant.

Understand the potential risk when you manage your keys

As with any business critical application, personnel within your organization who have administrative-level access must be trusted. Before you use the key management feature, you should understand the risk when you manage your database encryption keys. It is conceivable that a malicious administrator (a person who is granted or has gained administrator-level access with intent to harm an organization's security or business processes) working within your organization might use the manage keys feature to create a key and use it to lock all environments in the tenant.

Consider the following sequence of events.

The malicious administrator signs in to the Power Platform admin center, goes to the Environments tab and selects Manage encryption key. The malicious administrator then creates a new key with a password and downloads the encryption key to their local drive, and activates the new key. Now all the environment databases are encrypted with the new key. Next, the malicious administrator locks the tenant with the newly downloaded key, and then takes or deletes the downloaded encryption key.

These actions will result in disabling all the environments within the tenant from online access and make all database backups un-restorable.

Important

To prevent the malicious administrator from interrupting the business operations by locking the database, the managed keys feature doesn't allow tenant environments to be locked for 72 hours after the encryption key has changed or activated. Additionally, anytime an encryption key is changed for a tenant, all administrators receive an email message alerting them of the key change. This provides up to 72 hours for other administrators to roll back any unauthorized key changes.

Key management requirements

Privileges required

To use the manage keys feature you need one of the following privileges:

• Global admin membership.

• Office 365 Service administrators group membership.

• System administrator security role for the environment that you want to manage the encryption key.

Encryption key requirements

If you provide your own encryption key, your key must meet these requirements that are accepted by Azure Key Vault.

• The encryption key file format must be PFX or BYOK.

• 2048-bit RSA or RSA-HSM key type.

• PFX encryption key files must be password protected.

For more information about generating and transferring an HSM-protected key over the Internet see How to generate and transfer HSM-protected keys for Azure Key Vault.

Key management tasks

Ssrs Product Key

To simplify the key management tasks, the tasks are broken down into three areas:

Administrators can use the Power Platform admin center or the Microsoft.Xrm.OnlineManagementAPI PowerShell module cmdlets to perform the key management tasks described here.

Generate or upload the encryption key for a tenant

All encryption keys are stored in the Azure Key Vault, and there can only be one active key at any time. Since the active key is used to encrypt all the environments in the tenant, managing the encryption is operated at the tenant level. Once the key is activated, each individual environment can then be selected to use the key for encryption.

Use this procedure to set the manage key feature the first time for an environment or to change (or roll-over) an encryption key for an already self-managed tenant.

Warning

When you perform the steps described here for the first time you are opting in to self-managing your encryption keys. More information: Understand the potential risk when you manage your keys.

1. Sign in to the Power Platform admin center.

2. Select the Environments tab, and then select Manage encryption keys on the toolbar.

3. Select Confirm to acknowledge the manage key risk.

4. Select New key on the toolbar.

5. On the left pane, complete the details to generate or upload a key:

   • Select a Region. This option is only shown if your tenant has multiple regions.
   • Enter a Key name.
   • Choose from the following options:
     • To create a new key, select Generate new (.pfx). More information: Generate a new key (.pfx).
     • To use your own generated key, select Upload (.pfx or .byok). More information: Upload a key (.pfx or .byok).

6. Select Next.

7. The sims 4 mac pc original cd key generator. Email notification is sent to all administrators. More information: Encryption key change notification.

Generate a new key (.pfx)

1. Enter a password, and then re-enter the password to confirm.
2. Select Create, and then select the created file notification on your browser.
3. The encryption key .PFX file is downloaded to your web browser's default download folder. Save the file in a secure location (we recommend that this key is backed up along with its password).

To perform this task using PowerShell, see Get-CRMGenerateProtectionkey and Set-CrmTenantProtectionKey.

Upload a key (.pfx or .byok)

1. Select Upload the Key, select the .pfx or .byok¹ file, and then select Open.
2. Enter the password for the key, and then select Create.

¹ For .byok encryption key files, make sure you use the subscription id as shown on the screen when you export the encryption key from your local HSM. More information: How to generate and transfer HSM-protected keys for Azure Key Vault.

To perform this task using PowerShell, see New-CRMImportProtectionKey and Set-CrmTenantProtectionKey.

Note

To reduce the number of steps for the administrator to manage the key process, the key is automatically activated when it is uploaded the first time. All subsequent key uploads require an additional step to activate the key.

Activate an encryption key for a tenant

Once an encryption key is generated or uploaded for the tenant, it can be activated.

1. Sign in to the Power Platform admin center.
2. Select the Environments tab, and then select Manage encryption keys on the toolbar.
3. Select Confirm to acknowledge the manage key risk.
4. Select a key that has an Available state and then select Activate key on the toolbar.
5. Select Confirm to acknowledge the key change and that all administrators will be notified.More information: Encryption key change notification

When you activate a key for the tenant, it takes a while for the key management service to activate the key. The status of the Key state displays the key as Installing when the new or uploaded key is activated.Once the key is activated, the following occurs:

• All encrypted environments automatically get encrypted with the active key (there is no downtime with this action).
• When activated, the encryption key will be applied to all environments that are changed from Microsoft-provided to self-managed encryption key.

To perform this task using PowerShell, see Set-CrmProtectWithTenantKey.

Important

To streamline the key management process so that all environments are managed by the same key, the active key can't be updated when there are locked environments. All locked environments must be unlocked before a new key can be activated. If there are locked environments that don't need to be unlocked, they must be deleted.

Note

After an encryption key is activated, you can't activate another key for 24 hours.

Manage encryption for an environment

By default, each environment is encrypted with the Microsoft-provided encryption key. Once an encryption key is activated for the tenant, administrators can elect to change the default encryption to use the activated encryption key. To use the activated key, follow these steps.

Apply encryption key to an environment

1. Sign in to the Power Platform admin center.
2. Select the Environments tab.
3. Open a Microsoft-provided encrypted environment.
4. Select See all.
5. In the Environment Encryption section, select Manage.
6. Select Confirm to acknowledge the manage key risk.
7. Select Apply this key to accept changing the encryption to use the activated key.
8. Select Confirm to acknowledge that you are managing the key directly and that there is downtime for this action.

Return a managed encryption key back to Microsoft-provided encryption key

Returning to the Microsoft-provided encryption key configures the environment back to the default behavior where Microsoft manages the encryption key for you.

1. Sign in to the Power Platform admin center.
2. Select the Environments tab, and then select an environment that is encrypted with a self-managed key.
3. Select See all.
4. In the Environment Encryption section, select Manage, and then select Confirm.
5. Under Return to standard encryption management, select Return .
6. For production environments, confirm the environment by entering the environment's name.
7. Select Confirm to return to standard encryption key management.

To perform this task using PowerShell, see Set-CrmProtectWithMicrosoftKey.

Lock the tenant

Since there is only one active key per tenant, locking the encryption for the tenant disables all the environments that are in the tenant. All locked environments remain inaccessible to everyone, including Microsoft, until a Power Platform service admin in your organization unlocks it by using the key that was used to lock it.

Caution

You should never lock the tenant environments as part of your normal business process. When you lock a Common Data Service tenant, all the environments will be taken completely offline and they can't be accessed by anyone, including Microsoft. Additionally, services such as synchronization and maintenance are all stopped. If you decide to leave the service, locking the tenant can ensure that your online data is never accessed again by anyone.
Note the following about tenant environments locking:

• Locked environments can't be restored from backup.
• Locked environments are deleted if not unlocked after 28 days.
• You can't lock environments for 72 hours after an encryption key change.
• Locking a tenant locks all active environments within the tenant.

Important

• You must wait at least one hour after you lock active environments before you can unlock them.
• Once the lock process begins, all encryption keys with either an Active or Available state are deleted. The lock process can take up to an hour and during this time unlocking locked environments is not allowed.

1. Sign into the Power Platform admin center.
2. Select the Environments tab and then on the command bar select Manage encryption keys.
3. Select the Active key and then select Lock active environments.
4. On the right pane select Upload active key, browse to and select the key, enter the password, and then select Lock.
5. When prompted, enter the text that is displayed on your screen to confirm that you want to lock all environments in the region, and then select Confirm.

To lock a tenant using the PowerShell cmdlet, see Set-CrmLockTenantProtectedInstances.

Unlock locked environments

To unlock environments you must first upload and then activate the tenant encryption key with the same key that was used to lock the tenant. Please note that locked environments do not get unlocked automatically once the key has been activated. Each locked environment has to be unlocked individually.

Important

• You must wait at least one hour after you lock active environments before you can unlock them.
• The unlock process can take up to an hour. Once the key is unlocked, you can use the key to Manage encryption for an environment.
• You can't generate a new or upload an existing key until all locked environments are unlocked.

Unlock encryption key

1. Sign into the Power Platform admin center.
2. Select the Environments tab and then select Manage encryption keys.
3. Select the key that has a Locked state, and then on the command bar select Unlock key.
4. Select Upload locked key, browse to and select the key that was used to lock the tenant, enter the password, and then select Unlock.The key goes into an Installing state. You must wait until the key is in an Active state before you can unlock locked environments.
5. To unlock an environment, see the next section.

Unlock environments

1. Select the Environments tab, and then select the locked environment name.

   Tip

   Don't select the row. Select the environment name.

2. In the Details section, select See all to display the Details pane on the right.

3. In the Environment encryption section on the Details pane select Manage.

4. On the Environment encryption page select Unlock.

5. Select Confirm to confirm that you want to unlock the environment.

6. Repeat the previous steps to unlock additional environments.

To unlock an environment using the PowerShell cmdlet, see Set-CrmUnlockTenantProtectedInstance.

Environment database operations

A customer tenant can have environments that are encrypted using the Microsoft managed key and environments that are encrypted with the customer managed key. To maintain data integrity and data protection, the following controls are available when managing environment database operations.

1. RestoreThe environment to overwrite (the restored to environment) is restricted to the same environment that the backup was taken from or to another environment that is encrypted with the same customer managed key.

2. CopyThe environment to overwrite (the copied to environment) is restricted to another environment that is encrypted with the same customer managed key.

   Note

   If a Support Investigation environment was created to resolve support issue in a customer managed environment, the encryption key for the Support Investigation environment must be changed to customer managed key before the Copy environment operation can be performed.

3. ResetThe environment's encrypted data will be deleted including backups. After the environment is reset, the environment encryption will revert back to the Microsoft managed key.

Encryption key change notification

Important

When an encryption key is activated or changed, all administrators receive an email message alerting them of the change. This provides a means to allow other administrators to verify and confirm that the key was updated by an authorized administrator. Since it takes time to activate the key and to encrypt all the environments, and to send out the email notification, an encryption key can only be updated once every 24 hours.

See also

Microsoft.Xrm.OnlineManagementAPI PowerShell reference
SQL Server: Transparent Data Encryption (TDE)

By: Scott Murray Updated: 2014-09-02 Comments (6) Related: >Reporting Services Security

Problem

My SQL Server Reporting Services database and server are secure and only used internally; do I really need to backup the SSRS keys? Also, is there a command line tool to handle this process?

I seem to hear the above noted questions quite often. Alternately, I will hear a DBA who handles SSRS say that he / she is 'backing up the actual ReportingServices and ReportServiceTemp databases, so there is no need to backup the keys. All the data is retained in the databases, right?' One last quote, I hear, although not as often, is 'all our SSRS rdl files are kept in some sort of source control application / system (which is a great practice), so I do not need to backup the SSRS keys.' While all these questions / responses are responsible, none is a good reason to not backup your SSRS key.

Solution

This tip is intended to encourage everyone to be sure to backup their SSRS keys, potentially often. SSRS uses symmetric and asymmetric keys which are generated from the Windows OS. If your SSRS setup uses a farm approach with multiple instances, then every instance must use a copy of the symmetric key.

The actual SSRS items which are encrypted include:

• Data source credentials which are stored in the database in order to connect to external databases and data sources
• The actual symmetric key used by SSRS to encrypt data
• The unattended user account information which is used to connect to a remote server in order get external images or data
• Credentials used to connect to the Report Server database itself.

The encrypted values are stored both in the Reporting Services configuration files and in the Report Server database. In the event you restore a SSRS database to a new server, the encryption keys will need to be loaded onto the new server in order to allow that server to read and utilize all of the items noted in the above list. Otherwise an error will result when attempting to navigate to the Report Server. Furthermore, your embedded data sources would be unreadable if you add a new key. Of course you could recreate a SSRS key on the new server and then redeploy all the data sets, data sources, and reports. In that situation though, you would still have to recreate all the folders and more importantly, the security for those folders (and related reports). An easier alternative is the backup and restore the SSRS key, and specifically use the command line tool, rskeymgmt, to handle these tasks.

Working with the SSRS Keys

Two main methods exist for working with the SSRS key. First you can use SQL Server 2012 Reporting Services Configuration Manager; as part of Tim Ford's tip, SQL Server Reporting Services Configuration Tool, he covers, in great detail, using the SSRS Configuration Manager to backup and restore the SSRS key. In this tip, though, we will explain how to accomplish similar tasks using the rskeymgmt utility, which is one of the SSRS command line utility tools.

In order to work with a live data for the key process, we will use AdventureWorks 2012 SQL Server database; the database is available on Codeplex at http://msftdbprodsamples.codeplex.com/releases/view/55330. Once you download and install the SQL Server database, we will subsequently use the SSRS 2012 sample reports which can be downloaded at http://advworks2012sssrs.codeplex.com/releases/view/106799. We will assume that you have installed and initialized the SSRS instance and it is up and running.

The rskeymgmt utility can be found in the binn sub-directory of your SQL Server install directory. On my local server, it resides in: C:Program Files (x86)Microsoft SQL Server110ToolsBinn. Of course depending on the install process, your location may be different. Opening the command prompt and navigating to this directory, we can run rskeymgmt -? to get a list of arguments and additionally some example commands.

The top 7 arguments from the help list are the 7 methods that you will use most often. The remaining arguments play a support role to the other arguments. We should also note that you need to be an administrator on the machine which you will run rskeymgmt, and it must be a report server machine. Also, you can only manage a local key and not keys on remote machines. Last, you will need to run the command prompt in 'Run as Administrator' mode; otherwise you will get an Access Denied error as shown below.

To get started, we will use the -l list argument to see the servers which are connected to this report server database. The command would be: rskeymgmt.exe -l -i SQL2012. The successful running of this command is shown below. This particular machine contains several versions of SQL Server, so we also must specify the instance name 'SQL2012'.

If this server had been part of a farm scale out design, then the above command would have listed multiple servers. Of course using the command line allows you to automate the process especially if you have many servers upon which the key needs to be applied.

Extract / Backup the Key

To 'backup' or extract our key, we would issue the following command: rskeymgmt.exe -e -f c:toolsSSRS2012_key -p WeAreSecureT0day -i SQL2012.

For this command we specify the location where the key should be saved via the -f argument and a password for the key file via the -p argument. Note when you use the -f argument, you must also specify a password with the -p argument. As shown next, the key is extracted to the noted location; you even get a warning to 'SECURE THE FILE IN A SAFE LOCATION'.

Apply / Restore the Key

To 'apply' the key to a report server, we execute this command: rskeymgmt.exe -a -f c:toolsSSRS2012_key -p WeAreSecureT0day -i SQL2012. This command simply returns success when the key file is applied to the server as illustrated below.

Delete a Key

Two methods can be used to disengage a Report Server's access to the encrypted data. The first method is using the -d argument, and it stands as the most severe method in that it DELETES ALL encryption keys and encrypted data. When you use SSRS is in a multiple server / farm architecture, the -d / delete method removes all keys for all servers. In this case, the report server will no longer function until a new key is generated. For our example the command to issues to delete all encrypted data would be: rskeymgmt.exe -d -i SQL2012. Fortunately, the command prompts you to confirm that you want to delete the key, because, again, ALL key data is removed! This situation would be similar to restoring just the SSRS databases and having to create a new key.

Generate a New Key

After deleting our key using the -d option, we could regenerate a new key using the -s argument: rskeymgmt.exe -s -i SQL2012 as seen in the screen prints below. Please note that this process only regenerates the keys. It does not restore all the encrypted data, such as the data source connection information. You would have to read the connection data.

Remove a SSRS Instance

Alternately, a single instance of a Report Server can be removed by using the -r argument; this argument requires the installationID (see list -l option above). The syntax for this command is: rskeymgmt.exe -r xxyyzzz where xxyyzzz is replaced with the actual ID.

Rejoin a SSRS Farm

To have that server rejoin the scaled out SSRS farm, you could issue this command: rskeymgmt -j -m remotecomputerNameOnNetwork -n namedreportserverinstance -u administratoraccountOnRemoteComputer -v administratorpasswordOnRemoteComputer. Unfortunately, I do not have a farm environment to show you the exact examples. However, this method does NOT delete the key and encryption information in the database like the -d argument.

Output Error Messages

Finally, you can output error messages and information from the rskeymgmt utility to the SSRS Trace Log by adding the -t argument. For instance the command to extract the key would be: rskeymgmt.exe -e -f c:toolsSSRS2012_key -p WeAreSecureT0day -i SQL2012 -t .

The SSRS log file is saved in a location similar to: C:Program FilesMicrosoft SQL ServerMSRS11.SQL2012Reporting ServicesLogFiles and as illustrated subsequently. We also see in the screen prints a copy of the SSRS trace logs which reflect the extract command.

Conclusion

I cannot stress enough the importance of backing up your SSRS keys. The key backup process can be accomplished in two ways: either using Reporting Service Configuration Manager or the rskeymgmt command line utility. The rskeymgmt utility provides a method to backup and apply the SSRS symmetric key which is used to store data source connection and configuration data in the SSRS database and configuration file. This key is further used to allow multiple servers to join a SSRS database when used in a farm or scale out deployment of SSRS. You can also delete the key information, but you should be forewarned that all encrypted data is deleted along with the key when the delete command is used.

Next Steps

• SSRS Configuration Manager - http://msdn.microsoft.com/en-us/library/ms157133.aspx
• Scale out SSRS Deployment - http://msdn.microsoft.com/en-us/library/ms159114.aspx

About the author