## 1. Project Overview & Quickstart (coder/ipad) # ipad Open-source repository coder/ipad ### Repository Details - **Repository:** [coder/ipad](https://github.com/coder/ipad) - **Primary Language:** Code *Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.* ## 2. Official Technical Reference & Guides (coder/docs) ## File: README.md # Coder Docs [](#contributors-) This repository contains the documentation source files for [coder.com/docs](https://coder.com/docs). ## Contributing Is something confusing or unclear? Do you want to contribute something new? [Open an issue or pull request](https://github.com/coder/docs/issues/new)! Please refer to the [style guide](https://github.com/coder/styleguide) for general writing guidelines. You can preview contributions in the context of the site using pull request deploy previews. :rocket: Our documentation is published once a day. Expect any merged contributions to be live within 24 hours. ## Archived documentation versions [Documentation for older versions of Coder](https://github.com/coder/docs/branches/all) is available in the corresponding version branch. For example, you can find docs for Coder v1.19 in the `v1.19` branch. ## Interested in using Coder? [Contact our Technical Sales Team](https://coder.com/contact). ## Contributors ✨ Thanks goes to these wonderful people: | [**Mark Milligan**](https://github.com/sharkymark)[πŸ–‹](#content-sharkymark) [πŸ’‘](#example-sharkymark) [πŸ€”](#ideas-sharkymark) [🚧](#maintenance-sharkymark) [πŸ‘€](https://github.com/coder/docs/pulls?q=is%3Apr+reviewed-by%3Asharkymark) | [**Eric Paulsen**](https://github.com/ericpaulsen)[πŸ–‹](#content-ericpaulsen) [πŸ’‘](#example-ericpaulsen) [πŸ€”](#ideas-ericpaulsen) [🚧](#maintenance-ericpaulsen) [πŸ‘€](https://github.com/coder/docs/pulls?q=is%3Apr+reviewed-by%3Aericpaulsen) | [**Katie Horne**](https://github.com/khorne3)[πŸ–‹](#content-khorne3) [πŸ’‘](#example-khorne3) [πŸ€”](#ideas-khorne3) [🚧](#maintenance-khorne3) [πŸ‘€](https://github.com/coder/docs/pulls?q=is%3Apr+reviewed-by%3Akhorne3) | [**Charles Moog**](https://cmoog.io/)[πŸ–‹](#content-cmoog) [πŸ€”](#ideas-cmoog) [🚧](#maintenance-cmoog) [πŸ‘€](https://github.com/coder/docs/pulls?q=is%3Apr+reviewed-by%3Acmoog) | [**G r e y**](https://vapurrmaid.ca/)[πŸ–‹](#content-vapurrmaid) [πŸ’‘](#example-vapurrmaid) [πŸ€”](#ideas-vapurrmaid) [πŸš‡](#infra-vapurrmaid) [🚧](#maintenance-vapurrmaid) [πŸ‘€](https://github.com/coder/docs/pulls?q=is%3Apr+reviewed-by%3Avapurrmaid) | [**Ben Potter**](https://bpmct.net/)[πŸ“](#blog-bpmct) [πŸ–‹](#content-bpmct) [πŸ’‘](#example-bpmct) [πŸ€”](#ideas-bpmct) [🚧](#maintenance-bpmct) [πŸ‘€](https://github.com/coder/docs/pulls?q=is%3Apr+reviewed-by%3Abpmct) | [**Kyle Carberry**](https://carberry.com/)[πŸ–‹](#content-kylecarbs) [🎨](#design-kylecarbs) [πŸ€”](#ideas-kylecarbs) [πŸš‡](#infra-kylecarbs) [🚧](#maintenance-kylecarbs) [πŸ‘€](https://github.com/coder/docs/pulls?q=is%3Apr+reviewed-by%3Akylecarbs) | [**Colin Adler**](https://colin.vc/)[πŸ–‹](#content-coadler) | [**Faur Ioan-Aurel**](https://github.com/fioan89)[πŸ–‹](#content-fioan89) | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | [**Ammar Bandukwala**](https://ammar.io/)[πŸ–‹](#content-ammario) | [**Ashley McClelland**](https://github.com/ashumz)[πŸ“–](https://github.com/coder/docs/commits?author=ashumz) | [**CoderErik**](https://github.com/CoderErik)[πŸ“](#blog-CoderErik) [πŸ›](https://github.com/coder/docs/issues?q=author%3ACoderErik) | [**Jon Ayers**](https://github.com/sreya)[πŸ–‹](#content-sreya) | [**Nathan Potter**](https://github.com/nathanpotter)[πŸ–‹](#content-nathanpotter) | [**StΓ©phane Este-Gracias**](https://github.com/sestegra)[πŸ›](https://github.com/coder/docs/issues?q=author%3Asestegra) | [**Eric Paulsen**](https://ericpaulsen.io)[πŸ›](https://github.com/coder/docs/issues?q=author%3Aericpaulsen) [πŸ–‹](#content-ericpaulsen) [πŸ’‘](#example-ericpaulsen) [πŸ€”](#ideas-ericpaulsen) [🚧](#maintenance-ericpaulsen) | | | | [**Thomas Hughes**](https://iamhughes.com/)[πŸ’‘](#example-IAmHughes) [🚧](#maintenance-IAmHughes) [πŸ“Ή](#video-IAmHughes) [πŸ›](https://github.com/coder/docs/issues?q=author%3AIAmHughes) [πŸ–‹](#content-IAmHughes) [πŸ€”](#ideas-IAmHughes) | [**Bryan Lorette**](https://www.linkedin.com/in/blorette/)[πŸ›](https://github.com/coder/docs/issues?q=author%3Abalorette) | [**Mike Terhar**](https://brownfield.dev/)[πŸ–‹](#content-mterhar) [πŸ’‘](#example-mterhar) [πŸ€”](#ideas-mterhar) [🚧](#maintenance-mterhar) [πŸ“Ή](#video-mterhar) | [**Dean Sheather**](https://github.com/deansheather)[πŸ–‹](#content-deansheather) [πŸ’‘](#example-deansheather) [🚧](#maintenance-deansheather) [πŸ‘€](https://github.com/coder/docs/pulls?q=is%3Apr+reviewed-by%3Adeansheather) | [**Faris Huskovic**](https://github.com/fuskovic)[πŸ–‹](#content-fuskovic) [πŸ’‘](#example-fuskovic) | [**Jonathan Yu**](https://github.com/jawnsy)[πŸ–‹](#content-jawnsy) [πŸ’‘](#example-jawnsy) [πŸ€”](#ideas-jawnsy) [πŸš‡](#infra-jawnsy) [🚧](#maintenance-jawnsy) [πŸ‘€](https://github.com/coder/docs/pulls?q=is%3Apr+reviewed-by%3Ajawnsy) | [**Sloane Sturzenegger**](https://github.com/sloanesturz)[πŸ›](https://github.com/coder/docs/issues?q=author%3Asloanesturz) | | | | [**Garrett Delfosse**](https://github.com/f0ssel)[πŸ–‹](#content-f0ssel) [🚧](#maintenance-f0ssel) | [**Zakary French**](http://about.me/radruler)[πŸ›](https://github.com/coder/docs/issues?q=author%3ARadruler) | [**dmatking**](https://github.com/dmatking)[πŸ›](https://github.com/coder/docs/issues?q=author%3Admatking) | [**horizzzzon**](https://github.com/horizzzzon)[πŸ–‹](#content-horizzzzon) | [**Brian Begy**](https://github.com/brianbegy)[πŸ–‹](#content-brianbegy) | [**Cian Johnston**](https://cianjohnston.ie)[πŸ–‹](#content-johnstcn) | [**xbaun**](https://github.com/xbaun)[πŸ›](https://github.com/coder/docs/issues?q=author%3Axbaun) [πŸ–‹](#content-xbaun) | | | | [**Presley Pizzo**](http://www.linkedin.com/in/presleypizzo/)[πŸ–‹](#content-presleyp) | [**Lily Hoffman**](https://github.com/lilshoff)[πŸ›](https://github.com/coder/docs/issues?q=author%3Alilshoff) [πŸ–‹](#content-lilshoff) | [**Mukund Shah**](http://mukundshah.com)[πŸ›](https://github.com/coder/docs/issues?q=author%3Amukundshah) | | | | | | | --- ## File: guides/admin/awsrds.md # AWS RDS with IAM credentials In addition to using [user/password](../../setup/installation.md#connect-an-external-database) for database authentication, Coder supports connecting to Amazon RDS databases using IAM credentials. ## Requirements - An EKS cluster with an [IAM OIDC provider enabled](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html) - An RDS instance with [IAM authentication enabled](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.Enabling.html) ## Setup 1. [Create an IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) to use for database authentication. 1. Create an IAM policy for the role created in Step 1. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["rds-db:connect"], "Resource": [ "arn:aws:rds-db:us-east-2:1234567890:dbuser:db-ABCDEFGHIJKL01234/db_user" ] } ] } ``` 1. Add a Trust Relationship to the IAM role. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount::" } } } ] } ``` 1. Create a database user with the same name specified in the policy above, and grant them the `rds_iam` role. ```sql CREATE USER dbuser WITH LOGIN; GRANT rds_iam TO dbuser; GRANT CREATE ON DATABASE coder TO dbuser; ``` 1. Set the following values in your Helm chart and re-deploy Coder. ```yaml coderd: builtinProviderServiceAccount: annotations: # this role is assumed by the coderd pods, it must have correct IAM policy to connect to RDS "eks.amazonaws.com/role-arn": "arn:aws:iam::1234567890:role/example" postgres: host: "example.us-east-1.rds.amazonaws.com" port: "5432" user: "dbuser" database: "coder" # notice the password field is not used connector: "awsiamrds" default: enable: false ``` Documentation references: - [IAM database authentication for MariaDB, MySQL, and PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html) - [Creating a database account using IAM authentication](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.DBAccounts.html#UsingWithRDS.IAMDBAuth.DBAccounts.PostgreSQL) --- ## File: guides/admin/disable-downloads.md # File download disabling For security and compliance purposes, Coder site managers may choose to disable the downloading of files from Coder's built-in IDEs: To do so, [update your deployment's workspace template policy](../../admin/templates.md) to include the following definition: ```yaml kubernetes: env: policy: append value: - key: "CS_DISABLE_FILE_DOWNLOADS" # To enable, set to "true" or "1" value: "true" ``` This change will take effect _after_ the user rebuilds their workspaces. --- ## File: guides/admin/helm-charts.md # Helm charts This article will show you how to modify the default configuration values in Coder's Helm chart. > You can > [see the contents of Coder's Helm chart](https://github.com/coder/enterprise-helm/blob/master/values.yaml) > on GitHub. 1. Get a copy of your existing Helm chart and save it as `current-values.yaml` ```console helm show values coder/coder > current-values.yaml ``` 1. Open the `current-values.yaml` file using the text editor of your choice 1. Edit the `current-values.yaml` file as needed. **Be sure to remove the lines that you are _not_ modifying. Otherwise, the contents of `current-values.yaml` will override those in the default chart** 1. Save the `current-values.yaml` file 1. Update your Coder deployment with your new Helm chart values. Be sure to replace the placeholder value in the following command with your Coder version): ```console helm upgrade coder coder/coder -n coder --version= --values current-values.yaml ``` **Note:** You must complete this step every time you update the Helm chart values --- ## File: guides/admin/image-tag-names.md # Image tag names Coder uses image tags to determine the image variant to use when creating an workspace. Image tags are expressed using the following notation: ```text : ``` Examples include: ```text ubuntu:rolling ubuntu:latest ubuntu:20.04 mycorp/myproject:v1 ``` This article will walk you through how Coder handles image tags and what to consider when working with image tags. ## Rebuilds use the same tag, not the same image When modifying an existing image, be sure to consider whether the changes you're making will break existing workspaces built using that image. You may want to consider taking a semantic versioning view of your image tags for more critical images. ## Tag behavior The following examples show how different tagging schemes change how Coder uses the image tag. - If you build your workspace using a `ubuntu:rolling` or `ubuntu:latest` tag, Coder prompts you to rebuild for patches, security updates, and major version releases. If you're supporting a SaaS product or working on mobile apps, you can opt for this to ensure that your tools stay up-to-date. - If you build your workspace using a specific version tag (e.g., `ubuntu:20.04`), Coder will alert you regarding patches and security updates so that you rebuild your workspace (you won't get these fixes otherwise). Coder does not, however, alert you regarding minor releases (e.g., movement from `20.04` to `20.10`). This is a good option for those offering long-term support of software with lengthier version cycles or those supporting multiple versions where you expect to revert to a prior release to investigate and fix issues. - If you build your workspace using `mycorp/myproject:v1`, the image is associated with a specific project's major version. You can apply the `:v1` tag to the most recent build for the image, while you can use `:v1.3` or `:v1.3.1` to pull a more specific tag version. ## Recommendations - Use image names and tags that follow a consistent format across the organization so that users will be comfortable selecting either a _versioned_ or a _rolling_ tag. - To avoid pulling images from Docker Hub (or another external source), use internal registry names and tags or namespaces that are controlled by your organization. ## Sample tagging scheme Let's say that you have the following tag: ```text registry:port/company/department/software:majorversion ``` Here's the information that can be gleaned from the tag name: - `registry:port`: By using an internal image registry name, there's no risk of pulling an outside image with unapproved content - `company`: If you're using an internal registry, you can omit this parameter - `department`: Helps set the scope for who owns the image and therefore can patch/modify the image - `software`: Offers information about which software systems should be developed using the image - `majorversion`: Can correlate to a software stock; helpful in determining which version of various dependencies and build tools are present in the image The above recommendations are based on assumptions that may not apply to all organizations, and their applicability may change over time. There's no "right way" to tag your images, as long as your tags are meaningful to your teams and don't cause issues with your developers' workflows. --- ## File: guides/admin/logging.md # Logging Logging can help you understand what's happening under the hood of your Coder deployment and is useful for debugging and monitoring the health of your cluster. ## Accessing logs You can access your logs at any time by running: ```console kubectl -n coder logs ``` ## Exporting logs The following sections show how you can change your Helm chart values to export logs. > See our guide to [updating your Helm chart](helm-charts.md) if you're > unfamiliar with updating a Helm chart. Please note that: - Setting either the `/dev/stdout` or `/dev/stderr` value to an empty string to disable. - You can use `/dev/stdout` and `/dev/stderr` interchangeably, since both write to the pod's standard output and error directories. - Coder supports writing logs to multiple output targets. ## Human-readable logs This is the default value that's set in the Helm chart: ```yaml logging: human: /dev/stderr ``` When set, logs will be sent to the `/dev/stderr` file path and formatted for human readability. ## JSON-formatted logs You can get JSON-formatted logs by setting the `json` value: ```yaml logging: json: /dev/stderr ``` ## Sending logs to Google Stackdriver If you deployed your Kubernetes cluster to Google Cloud, you can send logs to Stackdriver: ```yaml logging: stackdriver: /dev/stderr ``` ## Sending logs to Splunk Coder can send logs directly to Splunk. Splunk uses the HTTP Event Collector (HEC) to receive data and application logs. See Splunk's docs for [information on configuring an HEC](https://docs.splunk.com/Documentation/Splunk/8.1.3/Data/UsetheHTTPEventCollector). Once you've configured an HEC, you'll need to update your Helm chart with your HTTP (HEC) endpoint and your HEC collector token. To provide your HTTP (HEC) endpoint: ```yaml logging: splunk: url: "" ``` To provide your HEC collector token: ```yaml logging: splunk: token: "" ``` Optionally, you can [specify the Splunk channel](https://docs.splunk.com/Documentation/Splunk/8.1.3/Data/AboutHECIDXAck#About_channels_and_sending_data) that you'd like associated with your messages. Channels allow logs to be segmented by client, preventing Coder application logs from affecting other client logs in your Splunk deployment. ```yaml logging: splunk: channel: "" ``` --- ## File: guides/admin/nfs.md # NFS file mounting This guide will walk you through configuring and mounting an NFS file share to a Coder workspace. The NFS file share will be separate from the user's persistent volume (represented as `/home/` in the workspace). ## Requirements To mount an NFS file share, you must use a container-based virtual machine (CVM) workspace with a FUSE device attached. You can enable both of these features in the admin panel by navigating to **Manage** > **Admin** > **Infrastructure** > **Workspace container runtime**. > Please review > [the CVM infrastructure requirements before enabling](https://coder.com/docs/coder/latest/admin/workspace-management/cvms) > CVMs and FUSE devices. The Coder workspace must have either `nfs-utils` or `nfs-common` installed. The server must have either `nfs-utils` or `nfs-kernel-server` installed. Ensure that no firewalls are blocking the client connections. By default, the NFS daemon is configured to run on a static port of `2049`. ## Server configuration steps 1. Create an NFS mount on the server for the clients to access: ```console export NFS_MNT_PATH=/mnt/nfs_share # Create directory to shaare sudo mkdir -p $NFS_MNT_PATH # Assign UID & GIDs access sudo chown -R uid:gid $NFS_MNT_PATH sudo chmod 777 $NFS_MNT_PATH ``` 1. Grant access to the clients by updating the `/etc/exports` file, which controls the directories shared with remote clients. See [Red Hat's docs for more information about the configuration options](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-nfs-server-config-exports). ```console # Provides read/write access to clients accessing the NFS from any IP address. /mnt/nfs_share *(rw,sync,no_subtree_check) ``` 1. Export the NFS file share directory. You must do this every time you change `/etc/exports`. ```console sudo exportfs -a sudo systemctl restart ``` ## Client (Coder workspace) configuration steps 1. Create a directory where the NFS mount will reside: ```console sudo mkdir -p /mnt/nfs_clientshare ``` 1. Mount the NFS file share from the server into your workspace: ```console sudo mount :/mnt/nfs_share /mnt/nfs_clientshare ``` --- ## File: guides/admin/oidc-adfs.md # OpenID Connect with Active Directory Federation Services (ADFS) This article walks you through setting up single sign-on to Coder using Azure's Active Directory Federation Services (ADFS). Configuring [Coder's OpenID Connect](../../admin/access-control/index.md#openid-connect) feature requires you to provide three pieces of information from Azure: - Client ID - Client Secret - Issuer This guide will show you how to set up Azure's Active Directory Federation Services and obtain the information you need to provide to Coder. ## Step 1: Create a new application group for Coder 1. On the server running ADFS, open Server Manager and go to **Tools** > **AD FS Management**. 1. In the left-hand pane, right-click on **Application Groups** and select **Add Application Group...**. 1. In the prompt window that appears, enter a **Name** and a **Description** (optional). Under **Template**, select **Server application accessing a web API**. Click **Next** to proceed. 1. In the next prompt window, you'll see a **Client identifier**. Save this value, since you'll need to provide it at a later step. Next, provide a **Redirect URI** (this value should be `https://coder.your-domain.com/oidc/callback`) and click **Add**. Then, click **Next** to proceed. 1. In the next screen, titled **Configure Application Credentials**, click the **Generate a shared secret** checkbox. Note the **Secret** value that appears, since you'll need to provide this to Coder at a later step. Click **Next** to proceed. 1. In the next step, **Configure Web API**, enter the **Client identifier** that you saved in step 4 in the field called **Identified** and click **Add**. Click **Next** to proceed. 1. On the **Choose Access Control Policy** screen, choose your preferred access control policy, and click **Next** to proceed. In the example below, we permit members of a specific group `coder-users` to access Coder. 1. For the step **Configure Application Permissions**, select the following **Permitted scopes**: - `allataclaims` - `email` - `openid` - `profile` Click **Next** to proceed. 1. Finally, in the **Summary** window, review the information you've provided. Click **Next** when you're ready to proceed and close the setup wizard. ## Step 2: Modify the claim rules In this step, you'll ensure that the access tokens sent by ADFS include the following [OIDC standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims): `name` and `email`. 1. In Server Manager, double-click on your newly created application group. 1. Under **Applications**, select the **Web API** application and click **Edit**. 1. Select the tab **Issuance Transform Rules** and click **Add Rule...**. This will open the **Add Transform Claim Rule Wizard**. 1. In the rule wizard, under **Claim rule template**, select the option to **Send Claims using a Custom Rule**, and click **Next**. 1. Enter a name for the claim rule. 1. In the **Custom Rule** field, enter a claim rule written in the [ADFS Claim Rule Language](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-the-claim-rule-language). The following example claim rule maps the Active Directory attributes `userPrincipalName` and `displayName` as `email` and `name`, respectively: ```text c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("email", "name"), query = ";userPrincipalName,displayName;{0}", param = c.Value); ``` > For more information, see > [Create a Rule to Send Claims Using a Custom Rule](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-rule-to-send-claims-using-a-custom-rule) ## Step 3: Gather information for Coder authentication Once you've created your application group, you'll have the **Client ID** and **Client Secret**. However, you still need the **issuer**, which you can get by running the `Get-ADFSProperties` Powershell cmdlet on the server running ADFS: ```console Get-ADFSProperties | Select IdTokenIssuer ``` You should see something similar for the output: ```console PS C:\Users\coder> Get-ADFSProperties | Select IdTokenIssuer IdTokenIssuer - - - - - - - https://dc1.ba3...da221.westeurope.aksapp.io/adfs ``` ## Step 4: Configure Coder authentication At this point, you can continue with configuring authentication in Coder. 1. Log into Coder and go to **Manage** > **Admin** > **Authentication**. 1. In the top-most drop-down box, select **OpenID Connect**. 1. Provide the requested values for **Client ID**, **Client Secret**, and **Issuer**. When done, click **Save Preferences**. At this point, Coder validates your configuration before proceeding. If successful, you can expect Coder to send OIDC login attempts to your configured ADFS instance. --- ## File: guides/admin/oidc-azuread.md # OpenID Connect with Azure AD This article walks you through setting up single sign-on to Coder using Azure's Active directory. Configuring [Coder's OpenID Connect](../../admin/access-control/index.md#openid-connect) feature requires you to provide three pieces of information from Azure: - Client ID - Client Secret - Issuer This guide will show you how to set up Azure's Active Directory and obtain the information you need to provide to Coder. ## Step 1: Register your app with Azure 1. Log in to [Azure](https://portal.azure.com/). 1. Using the search bar at the top, enter **App registrations** and click the matching search result. 1. Click **New registration**. 1. Provide a **Name** for your application. 1. Select the access option that best fits your needs; use **Default Directory only - Single tenant** unless your AD requires multi-tenancy. 1. Provide your **Redirect URL** (it will be formatted similar to `https://coder.exampleCo.com/oidc/callback`). 1. Click **Register** to proceed. When Azure has created your app, you'll be redirected to **Overview**, which displays the app information. ## Step 2: Gather your Azure app information Once you've registered your app, you can obtain your: - Client ID - Client Secret - Issuer ### Client ID On your application's **Overview**, look for the **Application (client) ID** under the **Essentials** section. This is the value Coder expects as the **Client ID**. ### Client secret You'll need to create the client secret. To do so: 1. Go to **Certificates & secrets**. 1. Click **New client secret**. 1. Provide a description for your secret and set an expiration date, and click **Add**. (We recommend creating a calendar notification to alert you shortly before your secret is set to expire.) 1. You'll be redirected back to the **Certificates & secrets** page; save the **Value** field string for use as your client secret. ### Issuer On your app's **Overview** page, click **Endpoints**. Find **OpenID Connect metadata document**, and copy the first 2/3s of this value. For example, if the full value is: ```text https://login.microsoftonline.com/6a8e8517-e411-4f53-a4b9-aba6f1646271/v2.0/.well-known/openid-configuration ``` Then remove `/.well-known/openid-configuration`, leaving the following as your issuer: ```text https://login.microsoftonline.com/6a8e8...6271/v2.0 ``` Be sure to keep `v2.0`, though you must omit the `/` from the end. > If there's an issue during the configuration process, the error message will > tell you the value you provided and the value it expected; you can use this > information to correct your configuration. ## Step 3: Configure Coder authentication Once you've saved your Azure values, you can complete the remaining steps using the Coder UI. 1. Log in to Coder, and go to **Manage** > **Admin** > **Authentication**. 1. In the top-most drop-down box, select **OpenID Connect**. 1. Provide the requested values for **Client ID**, **Client Secret**, and **Issuer**. Optionally, you can specify **Additional Scopes**. When done, click **Save Preferences**. At this point, Coder validates your configuration before proceeding. If successful, you can expect Coder to send OIDC login attempts to Azure.