# Extended Guide
{% hint style="warning" %}
SCEPman Enterprise Edition only
{% endhint %}
This will guide you through all steps to deploy SCEPman for an enterprise-grade environment with advanced requirements, e.g. naming conventions, redundancy or auto-scaling.
## Azure Deployment
Let's start with the requirements and a resource overview.\
Keep in mind that you need to plan a useful Azure resource design.
### Prerequisites
#### Mandatory
* [ ] Azure resource naming convention.
* [ ] Azure subscription (at least Contributor rights on that subscription).
* [ ] Azure owner rights (at least on Resource Group level).
* [ ] Microsoft Entra ID (Azure AD) "Global administrator" (Consent to access Graph API).
* [ ] Make sure to define your Azure policies [according to SCEPman requirements](https://docs.scepman.com/other/security-faq#azure-cis) (e.g. do not enforce TLS).
* [ ] Public Domain CNAME (*scepman.yourdomain.com*), only if geo-redundancy is used.
* [ ] SSL Certificate (or use [App Service Managed Certificate](https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-certificate#create-a-free-certificate-preview)), only if geo-redundancy is used.
* [ ] SCEPman Enterprise Edition License Key.
#### Optional
* [ ] Public Domain CNAME (*scepman.yourdomain.com*), only if a custom domain is used.
* [ ] SSL (Wildcard-) Certificate (or use [App Service Managed Certificate](https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-certificate#create-a-free-certificate-preview)), only if a custom domain is used.
### Azure Resource Overview
The following resources are recommended for a production environment.
| Type | Description |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| App Service (x2) | A virtual Azure environment to run the SCEPman Core and Cert Master applications and provides a UI to configure different
application specific settings like CNAME, SSL certificate and App Settings.
|
| App Service Plan | A virtual set of compute resources and configurations for the "App Service(s)".
Here you can configure the pricing tier and resource scaling.
|
| Key Vault | Tool to securely store secrets and certificates. The SCEPman application will generate and save the root certificate in your Key Vault. |
| Application Insights | Application Performance Management (APM) tool to get insights of the SCEPman applications and requests. Needed to measure performance and good for service optimization. |
| Storage account | Storage platform used by SCEPman's Certificate Master component to store certificates attributes for revocation purposes.
Optional:
The "App Service" will load the artifacts from a blob storage URI if manual updates are configured.
|
| Log Analytics workspace | A centralized and cloud-based log storage. The "App Service" will save all
platform logs and metrics into this workspace.
Since v3.0, SCEPman writes logs to the Log Analytics Workspace using Microsoft's Log Ingestion API.
|
Additionally, if you are using Private Endpoints, you have [seven additional Azure resources.](https://docs.scepman.com/azure-configuration/private-endpoints#azure-resources-used-for-private-endpoints)
| Type | Description |
|---|
| Virtual Network | The SCEPman App Services, the Key Vault, and the Storage Account connect over this VNET. |
| Private Endpoint (×2) | One for the Key Vault and one for the Storage Account. It makes them accessible over the VNET. |
| Private DNS zone (×2) | One for the Key Vault and one for the Storage Account. They both have an internal IP address in the VNET, for which they have a name in their respective Private DNS zone. |
| Network Interface (×2) | One for the Key Vault and one for the Storage Account. It connects the Private Endpoint to the VNET. |
## Configuration Steps
{% stepper %}
{% step %}
### Deploy SCEPman Base Services
{% hint style="warning" %}
This is a **mandatory** step.
{% endhint %}
Make your choice on whether you'd like to deploy with a **Windows** or **Linux** App Service Plan. Both deployment methods will allow you to choose your Operating System.
To start with the deployment, you need to follow our setup instructions leveraging an **ARM Template**
{% content-ref url="../deployment-options/enterprise-deployment" %}
[enterprise-deployment](https://docs.scepman.com/scepman-deployment/deployment-options/enterprise-deployment)
{% endcontent-ref %}
or alternatively our **Terraform** script:
{% content-ref url="../deployment-options/terraform-deployment" %}
[terraform-deployment](https://docs.scepman.com/scepman-deployment/deployment-options/terraform-deployment)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Perform Post-Deployment Steps (Permission Assignments)
{% hint style="warning" %}
This is a **mandatory** step.
{% endhint %}
To properly link all components of SCEPman, several permissions need to be assigned. Please follow these steps to establish the relevant connections:
{% content-ref url="../permissions/post-installation-config" %}
[post-installation-config](https://docs.scepman.com/scepman-deployment/permissions/post-installation-config)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Add Certificate Master Permissions
{% hint style="success" %}
This is a **mandatory** step for **Enterprise** **Edition** customers. **Community Edition** users may skip this step.
{% endhint %}
The Certificate Master is an **Enterprise Edition** feature that allows administrators to manually generate and revoke certificates. Please follow these steps to provide access to the Certificate Master.
{% content-ref url="../../scepman-configuration/rbac" %}
[rbac](https://docs.scepman.com/scepman-configuration/rbac)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Create Root Certificate
{% hint style="warning" %}
This is a **mandatory** step.
{% endhint %}
After the deployment and permission assignment is complete, you need to create the root certificate for SCEPman:
{% content-ref url="../first-run-root-cert" %}
[first-run-root-cert](https://docs.scepman.com/scepman-deployment/first-run-root-cert)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Configure a Custom Domain and SSL Certificate
{% hint style="success" %}
This is a **recommended** step. However, **skip** this step if you are implementing geo-redundancy.
{% endhint %}
To have your SCEPman available under your specific domain you need to create a **Custom Domain** in the **App Service.**
{% content-ref url="../../azure-configuration/custom-domain" %}
[custom-domain](https://docs.scepman.com/azure-configuration/custom-domain)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Manual Updates
{% hint style="info" %}
This is an **optional** step.
{% endhint %}
By default, SCEPman adopts an [evergreen approach](https://docs.scepman.com/azure-configuration/update-strategy#evergreen-approach) towards updates. In case you require full control over your SCEPman updates, please configure a deployment slot as described in the following guide under section **Deployment Slot Configuration**.
{% content-ref url="../../azure-configuration/update-strategy" %}
[update-strategy](https://docs.scepman.com/azure-configuration/update-strategy)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Deploy Application Insights
{% hint style="success" %}
This is **recommended** step.
{% endhint %}
The Application Insights can be used to get an overview of the App Service performance and to get deeper insights of the request processing of SCEPman. We recommend to always configure Application Insights to monitor, maintain and optimize the App Service.
{% content-ref url="../../azure-configuration/application-insights" %}
[application-insights](https://docs.scepman.com/azure-configuration/application-insights)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Configure Health Check
{% hint style="success" %}
This is **recommended** step.
{% endhint %}
Health Checks can be configured to notify administrators in the event the SCEPman App Service is unresponsive.
{% content-ref url="../../azure-configuration/health-check" %}
[health-check](https://docs.scepman.com/azure-configuration/health-check)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Ensure that SCEPman has sufficient resources
{% hint style="warning" %}
This is a **mandatory** step.
{% endhint %}
Once you move SCEPman into a production environment, you should ensure that SCEPman is equipped with sufficient computing power. Therefore, please review our Azure Sizing guide and upgrade your App Service Plan tier if need be. You may postpone this until after your PoC or trial phase.
{% content-ref url="../../azure-configuration/azure-sizing" %}
[azure-sizing](https://docs.scepman.com/azure-configuration/azure-sizing)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Configure Autoscaling
{% hint style="info" %}
This is an **optional** step.
{% endhint %}
The SCEPman solution has two different tasks and performance requirements.\
One task is the certificate issuance process: After the configuration of the SCEPman solution we need to deploy certificates to all devices (user and/or device certificates), but this is a one-time-task and after the initial deployment this only happens when a new device is enrolled, or the certificates needs to be renewed. In those situations, the SCEPman will face a peek of SCEP requests.
The second task is the certificate validation: After we deployed certificates to devices, those certificates need to be validated each time we use them. For every certificated-based authentication the clients, gateways, or RADIUS system (depends on what you use) will send an OCSP request to the SCEPman App Service. This will cause a permanent request load on the App Service.
To have an optimized performance and take care of the costs we recommend to setup the Autoscaling functionality of the App Service. With this feature your application can scale-out and scale-in based on metrics.
{% content-ref url="../../azure-configuration/azure-sizing/autoscaling" %}
[autoscaling](https://docs.scepman.com/azure-configuration/azure-sizing/autoscaling)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Configure Geo-Redundancy
{% hint style="info" %}
This is an **optional** step.
{% endhint %}
Configuring a geo-redundant instance for SCEPman can enhance service availability and resilience by distributing workloads across multiple Azure regions.
However, it's important to note that this setup may lead to increased Azure costs due to the additional resources and data replication involved. Microsoft provides an SLA of 99.95% for Azure App Services, which is adequate in most scenarios.
{% content-ref url="../../azure-configuration/geo-redundancy" %}
[geo-redundancy](https://docs.scepman.com/azure-configuration/geo-redundancy)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Configure your MDM Deployment Profiles
{% hint style="success" %}
This is a **recommended** step.
{% endhint %}
With the completion of the above steps, we have a working SCEPman implementation and can now deploy certificates to the devices.
Please use one (or more) of the following articles, to deploy certificates with your preferred MDM solution:
{% content-ref url="../../certificate-management/microsoft-intune" %}
[microsoft-intune](https://docs.scepman.com/certificate-management/microsoft-intune)
{% endcontent-ref %}
{% content-ref url="../../certificate-management/jamf" %}
[jamf](https://docs.scepman.com/certificate-management/jamf)
{% endcontent-ref %}
{% content-ref url="../../certificate-management/static-certificates" %}
[static-certificates](https://docs.scepman.com/certificate-management/static-certificates)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Manually Issue Certificates or sign CSRs using the Certificate Master
{% hint style="info" %}
This is an **optional** step.
{% endhint %}
Please follow below link, to learn how to issue TLS server certificates based on a list of FQDNs or sign any CSR using the Certificate Master component.
{% content-ref url="../../certificate-management/certificate-master" %}
[certificate-master](https://docs.scepman.com/certificate-management/certificate-master)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Issue Certificates using the Enrollment REST API
{% hint style="info" %}
This is an **optional** step.
{% endhint %}
SCEPman features a REST API to enroll certificates. This is an alternative to the SCEP endpoints that require the SCEP-style of authentication, while the REST API uses Microsoft Identities for authentication. The protocol is also much simpler than SCEP.
{% content-ref url="../../certificate-management/api-certificates" %}
[api-certificates](https://docs.scepman.com/certificate-management/api-certificates)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Create Locks on SCEPman Azure resources
{% hint style="info" %}
This is an **optional** step.
{% endhint %}
By default, SCEPman does not apply any locks to Azure resources. If you use resource locks and wish to configure them, the following list outlines which lock types can be applied to each SCEPman resource.
* **Key Vault:** Soft Delete and Purge Protection already provide protection against accidental deletion. SCEPman does not modify the resource after CA key creation, so a **ReadOnlyLock** is technically possible.
* **Storage Account:** Only a **DeleteLock** is possible, as SCEPman needs to write certificate information into the table. If a Storage Account is accidentally deleted, you lose information about already issued certificates.
* **App Services:** A **ReadOnlyLock** is theoretically possible, but it must be removed each time you modify the SCEPman configuration. A deleted App Service can easily be reinstalled, but it will only have the default configuration, so all manual changes must be reconfigured manually. A combination of **DeleteLock** and **ReadOnlyLock** helps mitigate this risk.
* **Log Analytics Workspace:** A **DeleteLock** is technically possible, but you would only lose logs collected during the retention period, which does not impact the availability of the SCEPman service.
* **Other Azure Resources:** These do not store data and can be recreated without loss of information. A **DeleteLock** and **ReadOnlyLock** can be useful for some of them. Some cannot be deleted at all because they have dependencies on one of the core services mentioned above.
{% endstep %}
{% endstepper %}