diff --git a/_data/toc.yaml b/_data/toc.yaml index a709124f9e..a971a1dfed 100644 --- a/_data/toc.yaml +++ b/_data/toc.yaml @@ -342,9 +342,9 @@ guides: - path: /deploy/rbac/howto-wordpress-view-only/ title: Deploy service with view-only access - path: /deploy/rbac/howto-orcabank1-standard/ - title: Orcabank tutorial with Docker EE Standard + title: Orcabank example with Docker EE Standard - path: /deploy/rbac/howto-orcabank2-advanced/ - title: Orcabank tutorial with Docker EE Advanced + title: Orcabank example with Docker EE Advanced - sectiontitle: Deploy your app in production section: diff --git a/deploy/rbac/howto-wordpress-multitier.md b/deploy/rbac/howto-wordpress-multitier.md index 3d1a49e909..7fd28509d4 100644 --- a/deploy/rbac/howto-wordpress-multitier.md +++ b/deploy/rbac/howto-wordpress-multitier.md @@ -23,11 +23,12 @@ control (RBAC). ## Swarm Stack In this section, we deploy `acme-blog` as a Swarm stack of two services. See -[Kubernetes Deployment](#kubernetes-deployment) for the same exersice with +[Kubernetes Deployment](#kubernetes-deployment) for the same exercise with Kubernetes. -You are the UCP admin at Acme Company and need to secure access to `acme-blog` -and its component services, Wordpress and MySQL. The best way to do this is to: +You are the Docker EE admin at Acme Company and need to secure access to +`acme-blog` and its component services, Wordpress and MySQL. The best way to do +this is to: - Add teams and users - Create collections (directories) for storing the resources of each component. @@ -48,12 +49,13 @@ acme-datacenter └── ops   └── Chad Chavez ``` -See [Create and configure users and teams](./usermgmt-create-subjects.md) +See: [Create and configure users and teams](./usermgmt-create-subjects.md). ### Create collection paths -Create three nested Swarm collections. First, create a collection for `acme-blog` in -the `Shared` collection and then nest collections for wordpress and mysql resources: +Create three nested Swarm collections. First, create a collection for +`acme-blog` in the `Shared` collection and then nest collections for wordpress +and mysql resources: ``` / @@ -66,7 +68,7 @@ the `Shared` collection and then nest collections for wordpress and mysql resour > **Tip**: To drill into a collection, click **View Children**. -See [Group and isolate cluster resources](./resources-group-resources.md) +See: [Group and isolate cluster resources](./resources-group-resources.md). ### Grant roles @@ -78,11 +80,11 @@ Create three grants with built-in roles: > In this exercise we use built-in roles but you can create custom ones too. -See: [Grant access to cluster resources](./usermgmt-grant-permissions.md) +See: [Grant access to cluster resources](./usermgmt-grant-permissions.md). ### Deploy Swarm stack with Wordpress and MySQL -You've configured UCP. The `ops` team can now deploy `acme-blog`: +You've configured Docker EE. The `ops` team can now deploy `acme-blog`: 1. Click **Shared Resources** > **Stacks**. 2. Click **Create Stack**. @@ -145,7 +147,7 @@ networks: ### Test access -Log on to UCP as each user and ensure that +Log on to the Docker EE UI as each user and ensure that - `dba` (alex) can only see and access `mysql-collection` - `dev` (bett) can only see and access `wordpress-collection` - `ops` (chad) can see and access both. @@ -168,8 +170,9 @@ In this section, we deploy `acme-blog` with Kubernetes. In this section, we deploy `acme-blog` as a Swarm stack of two services. -You are the UCP admin at Acme Company and need to secure access to `acme-blog` -and its component services, Wordpress and MySQL. The best way to do this is to: +You are the Docker EE admin at Acme Company and need to secure access to +`acme-blog` and its component services, Wordpress and MySQL. The best way to do +this is to: - Add teams and users - Create collections (directories) for storing the resources of each component. @@ -190,12 +193,13 @@ acme-datacenter └── ops   └── Chad Chavez ``` -See [Create and configure users and teams](./usermgmt-create-subjects.md) +See: [Create and configure users and teams](./usermgmt-create-subjects.md). ### Create collection paths -Create three nested Swarm collections. First, create a collection for `acme-blog` in -the `Shared` collection and then nest collections for wordpress and mysql resources: +Create three nested Swarm collections. First, create a collection for +`acme-blog` in the `Shared` collection and then nest collections for wordpress +and mysql resources: ``` / @@ -220,11 +224,11 @@ Create three grants with built-in roles: > In this exercise we use built-in roles but you can create custom ones too. -See: [Grant access to cluster resources](./usermgmt-grant-permissions.md) +See: [Grant access to cluster resources](./usermgmt-grant-permissions.md). ### Deploy Swarm stack with Wordpress and MySQL -You've configured UCP. The `ops` team can now deploy `acme-blog`: +You've configured Docker EE. The `ops` team can now deploy `acme-blog`: 1. Click **Shared Resources** > **Stacks**. 2. Click **Create Stack**. @@ -287,7 +291,7 @@ networks: ### Test access -Log on to UCP as each user and ensure that +Log on to the Docker EE UI as each user and ensure that: - `dba` (alex) can only see and access `mysql-collection` - `dev` (bett) can only see and access `wordpress-collection` - `ops` (chad) can see and access both. diff --git a/deploy/rbac/howto-wordpress-view-only.md b/deploy/rbac/howto-wordpress-view-only.md index 760755c744..b9a4cff375 100644 --- a/deploy/rbac/howto-wordpress-view-only.md +++ b/deploy/rbac/howto-wordpress-view-only.md @@ -32,10 +32,10 @@ collection that contains one Swarm service. ### Create an organization -Create an organization with one team, and add one user who isn't an administrator -to the team. +Create an organization with one team, and add one user who isn't an +administrator to the team. -1. Log in to UCP as an administrator. +1. Log in to the Docker EE UI as an administrator. 2. Navigate to the **Organizations & Teams** page and click **Create Organization**. Name the new organization `engineering` and click **Create**. @@ -134,10 +134,10 @@ collection that contains one Swarm service. ### Create an organization -Create an organization with one team, and add one user who isn't an administrator -to the team. +Create an organization with one team, and add one user who isn't an +administrator to the team. -1. Log in to UCP as an administrator. +1. Log in to the Docker EE UI as an administrator. 2. Navigate to the **Organizations & Teams** page and click **Create Organization**. Name the new organization `engineering` and click **Create**. diff --git a/deploy/rbac/index.md b/deploy/rbac/index.md index 9708a45dbc..b0b8fd31f9 100644 --- a/deploy/rbac/index.md +++ b/deploy/rbac/index.md @@ -22,15 +22,15 @@ next_steps: {% if include.ui %} -With [Docker Universal Control Plane (UCP)](https://docs.docker.com/datacenter/ucp/2.2/guides/), -you can authorize how users view, edit, and use cluster resources by granting -role-based permissions. Resources can be grouped and isolated according to an +The Docker Enterprise Edition UI, or the Docker Univeral Control Plane (UCP), +lets you authorize users to view, edit, and use cluster resources by granting +role-based permissions. Resources can be grouped and isolated inline with an organization's needs and users can be granted more than one role. {% if include.version=="ucp-3.0" %} -To authorize access to cluster resources across your organization, Docker +To authorize access to cluster resources across your organization, Docker EE administrators might take the following high-level steps: - Add and configure **subjects** (users and teams). @@ -39,9 +39,11 @@ administrators might take the following high-level steps: - Group cluster **resources** into Swarm collections or Kubernetes namespaces. - Create **grants** by marrying subject + role + resource. +For a simple example, see [Deploy a multi-tier application with RBAC](./howto-wordpress-multitier). + ## Subjects -A subject represents a user, team, or organization. A subject is granted a +A subject represents a user, team, or organization. A subject can be granted a role that defines permitted operations against one or more resource types. - **User**: A person authenticated by the authentication backend. Users can @@ -76,9 +78,9 @@ For more, see: [Define roles with authorized API operations](./usermgmt-define-r Cluster resources are grouped into Swarm collections or Kubernetes namespaces. A collection is a directory that holds Swarm resources. You can create -collections in UCP by defining a path and moving resources. Or you can create -the path in UCP and use *labels* in your YAML file to assign application -resources to that path. For an example, see [Deploy a multi-tier service with multiple roles](/deploy/rbac/howto-wordpress-multitier/). +collections in the Docker EE UI by defining a path and moving resources. Or you +can create the path in the Docker EE UI and use *labels* in your YAML file to +assign application resources to that path. For an example, see [Deploy a multi-tier service with multiple roles](/deploy/rbac/howto-wordpress-multitier/). > Resource types that can be placed into a Swarm collection include: Containers, > Networks, Nodes, Services, Secrets, and Volumes. @@ -113,7 +115,7 @@ For more, see: [Grant access to cluster resources](./usermgmt-grant-permissions. {% elsif include.version=="ucp-2.2" %} -To authorize access to cluster resources across your organization, Docker +To authorize access to cluster resources across your organization, Docker EE administrators might take the following high-level steps: - Add and configure **subjects** (users and teams) @@ -159,9 +161,9 @@ For more, see: [Define roles with authorized API operations](./usermgmt-define-r Cluster resources are grouped into Swarm collections. A collection is a directory that holds Swarm resources. You can create -collections in UCP by defining a path and moving resources. Or you can create -the path in UCP and use *labels* in your YAML file to assign application -resources to that path. For an example, see [Deploy a multi-tier service with multiple roles](./deploy/rbac/howto-wordpress-multitier/). +collections in the Docker EE UI by defining a path and moving resources. Or you +can create the path in the Docker EE UI and use *labels* in your YAML file to +assign application resources to that path. For an example, see [Deploy a multi-tier service with multiple roles](./deploy/rbac/howto-wordpress-multitier/). > Resource types that can be placed into a Swarm collection include: Containers, > Networks, Nodes, Services, Secrets, and Volumes. diff --git a/deploy/rbac/resources-group-resources.md b/deploy/rbac/resources-group-resources.md index 164cb8e7cd..13dbdc6400 100644 --- a/deploy/rbac/resources-group-resources.md +++ b/deploy/rbac/resources-group-resources.md @@ -23,6 +23,138 @@ next_steps: {% if include.ui %} {% if include.version=="ucp-3.0" %} +## Swarm collection + +A collection is a directory of grouped resources, such as services, containers, +volumes, networks, and secrets. To authorize access, administrators create +grants against directory branches. + +![](../images/collections-and-resources.svg){: .with-border} + +## Access label + +Access to a collection is granted with a path defined in an access label. + +For example, each user has a private collection (with default permisions) and +the path is `/Shared/Private/`. The private collection for user "hans" +would have the following access label: + +``` +com.docker.ucp.access.label = /Shared/Private/hans +``` + +## Nested collections + +You can nest collections. If a user has a grant against a collection, the grant +applies to all of its child collections. + +For a child collection, or for a user who belongs to more than one team, the +system concatenates permissions from multiple roles into an "effective role" for +the user, which specifies the operations that are allowed against the target. + +> **Note**: Permissions are concatenated from multiple roles into an "effective +> role". + +## Built-in collections + +Docker EE provides a number of built-in collections. + +| Default collection | Description | +| ------------------ | --------------------------------------------------------------------------------------- | +| `/` | Path to all resources in the Swarm cluster. Resources not in a collection are put here. | +| `/System` | Path to UCP managers, DTR nodes, and UCP/DTR system services. By default, only admins have access, but this is configurable. | +| `/Shared` | Default path to all worker nodes for scheduling. In Docker EE Standard, all worker nodes are located here. In [Docker EE Advanced](https://www.docker.com/enterprise-edition), worker nodes can be moved and [isolated](./resources-isolate-nodes/). | +| `/Shared/Private/` | Path to a user's private collection. | +| `/Shared/Legacy` | Path to the access control labels of legacy versions (UCP 2.1 and lower). | + + +This diagram shows the `/System` and `/Shared` collections created by Docker EE. +User private collections are children of the `/Shared/private` collection. The +Docker EE administrator user created a `/prod` collection and a child +collection, `/webserver`. + +![](../images/collections-diagram.svg){: .with-border} + +## Default collections + +Each user has a default collection which can be changed and in the Docker EE UI preferences. + +Users can't deploy a resource without a collection. When a user deploys a +resource in the CLI without an access label, Docker EE automatically places the +resource in the user's default collection. + +[Learn how to add labels to nodes](../../datacenter/ucp/2.2/guides/admin/configure/add-labels-to-cluster-nodes/). + +With Docker Compose, the system applies default collection labels across all +resources in the stack unless `com.docker.ucp.access.label` has been explicitly +set. + +> Default collections and collection labels +> +> Default collections are good for users who ony work on a well-defined slice of +> the system, as well as users who deploy stacks and don't want to edit the +> contents of their compose files. A user with more versatile roles in the +> system, such as an adminitrator, might find it better to set custom labels for +> each resource. + +## Collections and labels + +Resources are marked as being in a collection by using labels. Some resource +types don't have editable labels, so you can't move resources like this across +collections. You can't modify collections after resource creation for +containers, networks, and volumes, but you can update labels for services, +nodes, secrets, and configs. + +For editable resources, like services, secrets, nodes, and configs, you can +change the `com.docker.ucp.access.label` to move resources to different +collections. With the CLI, you can use this label to deploy resources to a +collection other than your default collection. Omitting this label on the CLI +deploys a resource on the user's default resource collection. + +The system uses the additional labels, `com.docker.ucp.collection.*`, to enable +efficient resource lookups. By default, nodes have the +`com.docker.ucp.collection.root`, `com.docker.ucp.collection.shared`, and +`com.docker.ucp.collection.swarm` labels set to `true`. The Docker EE UI +automatically controls these labels, and you don't need to manage them. + +Collections get generic default names, but you can give them meaningful names, +like "Dev", "Test", and "Prod". + +A *stack* is a group of resources identified by a label. You can place the +stack's resources in multiple collections. Resources are placed in the user's +default collection unless you specify an explicit `com.docker.ucp.access.label` +within the stack/compose file. + +## Control access to nodes + +The Docker EE Advanced license enables access control on worker nodes. Admin +users can move worker nodes from the default `/Shared` collection into other +collections and create corresponding grants for scheduling tasks. + +In this example, an administrator has moved worker nodes to a `/prod` +collection: + +![](../images/containers-and-nodes-diagram.svg) + +When you deploy a resource with a collection, Docker EE sets a constraint +implicitly based on what nodes the collection, and any ancestor collections, can +access. The `Scheduler` role allows users to deploy resources on a node. By +default, all users have the `Scheduler` role against the `/Shared` collection. + +When deploying a resource that isn't global, like local volumes, bridge +networks, containers, and services, the system identifies a set of "schedulable +nodes" for the user. The system identifies the target collection of the +resource, like `/Shared/Private/hans`, and it tries to find the parent that's +closest to the root that the user has the `Node Schedule` permission on. + +For example, when a user with a default configuration runs `docker container run +nginx`, the system interprets this to mean, "Create an NGINX container under the +user's default collection, which is at `/Shared/Private/hans`, and deploy it on +one of the nodes under `/Shared`. + +If you want to isolate nodes against other teams, place these nodes in new +collections, and assign the `Scheduler` role, which contains the `Node Schedule` +permission, to the team. [Isolate swarm nodes to a specific team](isolate-nodes-between-teams.md). {% elsif include.version=="ucp-2.2" %} @@ -61,7 +193,7 @@ the user, which specifies the operations that are allowed against the target. ## Built-in collections -UCP provides a number of built-in collections. +Docker EE provides a number of built-in collections. | Default collection | Description | | ------------------ | --------------------------------------------------------------------------------------- | @@ -72,18 +204,19 @@ UCP provides a number of built-in collections. | `/Shared/Legacy` | Path to the access control labels of legacy versions (UCP 2.1 and lower). | -This diagram shows the `/System` and `/Shared` collections created by UCP. User -private collections are children of the `/Shared/private` collection. The UCP -admin user created a `/prod` collection and a child collection, `/webserver`. +This diagram shows the `/System` and `/Shared` collections created by Docker EE. +User private collections are children of the `/Shared/private` collection. The +Docker EE administrator user created a `/prod` collection and a child +collection, `/webserver`. ![](../images/collections-diagram.svg){: .with-border} ## Default collections -Each user has a default collection which can be changed and set in the UI preferences. +Each user has a default collection which can be changed and in the Docker EE UI preferences. Users can't deploy a resource without a collection. When a user deploys a -resource in the CLI without an access label, UCP automatically places the +resource in the CLI without an access label, Docker EE automatically places the resource in the user's default collection. [Learn how to add labels to nodes](../../datacenter/ucp/2.2/guides/admin/configure/add-labels-to-cluster-nodes/). @@ -117,8 +250,8 @@ deploys a resource on the user's default resource collection. The system uses the additional labels, `com.docker.ucp.collection.*`, to enable efficient resource lookups. By default, nodes have the `com.docker.ucp.collection.root`, `com.docker.ucp.collection.shared`, and -`com.docker.ucp.collection.swarm` labels set to `true`. UCP automatically -controls these labels, and you don't need to manage them. +`com.docker.ucp.collection.swarm` labels set to `true`. The Docker EE UI +automatically controls these labels, and you don't need to manage them. Collections get generic default names, but you can give them meaningful names, like "Dev", "Test", and "Prod". @@ -139,10 +272,10 @@ collection: ![](../images/containers-and-nodes-diagram.svg) -When you deploy a resource with a collection, UCP sets a constraint implicitly -based on what nodes the collection, and any ancestor collections, can access. -The `Scheduler` role allows users to deploy resources on a node. By default, all -users have the `Scheduler` role against the `/Shared` collection. +When you deploy a resource with a collection, Docker EE sets a constraint +implicitly based on what nodes the collection, and any ancestor collections, can +access. The `Scheduler` role allows users to deploy resources on a node. By +default, all users have the `Scheduler` role against the `/Shared` collection. When deploying a resource that isn't global, like local volumes, bridge networks, containers, and services, the system identifies a set of "schedulable diff --git a/deploy/rbac/usermgmt-create-subjects.md b/deploy/rbac/usermgmt-create-subjects.md index f8138c59a0..4370c2a641 100644 --- a/deploy/rbac/usermgmt-create-subjects.md +++ b/deploy/rbac/usermgmt-create-subjects.md @@ -22,8 +22,8 @@ next_steps: {% if include.ui %} -Users, teams, and organizations are referred to as subjects in Docker Universal -Control Plane (UCP). +Users, teams, and organizations are referred to as subjects in Docker Enterprise +Edition. Individual users can belong to one or more teams but each team can only be in one organization. At the fictional startup, Acme Company, all teams in the @@ -42,10 +42,10 @@ acme-datacenter ## Authentication -All users are authenticated on the backend. UCP provides built-in authentication -and also integrates with LDAP directory services. +All users are authenticated on the backend. Docker EE provides built-in +authentication and also integrates with LDAP directory services. -To use UCP built-in authentication, you must [create users manually](#Create-users-manually). +To use Docker EE's built-in authentication, you must [create users manually](#Create-users-manually). > To enable LDAP and authenticate and synchronize UCP users and teams with your > organization's LDAP directory, see: @@ -54,7 +54,7 @@ To use UCP built-in authentication, you must [create users manually](#Create-use ## Build an organization architecture -The general flow of designing an organization with teams in UCP is: +The general flow of designing an organization with teams in the Docker EE UI is: 1. Create an organization. 2. Add users or enable LDAP. @@ -63,7 +63,7 @@ The general flow of designing an organization with teams in UCP is: ### Create an organization with teams -To create an organzation in UCP: +To create an organzation in the Docker EE UI: 1. Click **Organization & Teams** under **User Management**. 2. Click **Create Organization**. @@ -88,10 +88,10 @@ To create teams in the organization: ### Create users manually New users are assigned a default permission level so that they can access the -cluster. To extend a user's default permissions, add them to a team and [create grants](./usermgmt-grant-permissions/). You can optionally grant them UCP +cluster. To extend a user's default permissions, add them to a team and [create grants](./usermgmt-grant-permissions/). You can optionally grant them Docker EE administrator permissions. -To manally create users in UCP: +To manally create users in the Docker EE UI: 1. Click **Users** under **User Management**. 2. Click **Create User**. @@ -111,10 +111,10 @@ To manally create users in UCP: ### Create users manuallly New users are assigned a default permission level so that they can access the -cluster. To extend a user's default permissions, add them to a team and [create grants](/deploy/rbac/usermgmt-grant-permissions/). You can optionally grant them UCP +cluster. To extend a user's default permissions, add them to a team and [create grants](/deploy/rbac/usermgmt-grant-permissions/). You can optionally grant them Docker EE administrator permissions. -To manally create users in UCP: +To manally create users in the Docker EE UI: 1. Navigate to the **Users** page. 2. Click **Create User**. diff --git a/deploy/rbac/usermgmt-define-roles.md b/deploy/rbac/usermgmt-define-roles.md index 178f6b14c0..061dc90063 100644 --- a/deploy/rbac/usermgmt-define-roles.md +++ b/deploy/rbac/usermgmt-define-roles.md @@ -24,7 +24,7 @@ Roles are applied to users and teams with grants. ![Diagram showing UCP permission levels](../images/permissions-ucp.svg) - ## Default roles +## Default roles You can define custom roles or use the following built-in roles: diff --git a/deploy/rbac/usermgmt-grant-permissions.md b/deploy/rbac/usermgmt-grant-permissions.md index a64f454b7a..6f90c18962 100644 --- a/deploy/rbac/usermgmt-grant-permissions.md +++ b/deploy/rbac/usermgmt-grant-permissions.md @@ -20,8 +20,8 @@ next_steps: {% if include.ui %} -UCP administrators can create *grants* to control how users and organizations -access resources. +Docker EE administrators can create *grants* to control how users and +organizations access resources. A grant is made up of *subject*, *role*, and *resource group*. @@ -60,9 +60,10 @@ A common workflow for creating grants has four steps: ### Create a Swarm grant -You can create grants after creating users, collections, and roles (if using custom roles). +You can create grants after creating users, collections, and roles (if using +custom roles). -To create a grant in UCP: +To create a grant in the Docker EE UI: 1. Click **Grants** under **User Management**. 2. Click **Create Grant**. @@ -73,8 +74,8 @@ To create a grant in UCP: 4. Click **Create**. > By default, all new users are placed in the `docker-datacenter` organization. -> To apply a grant to all UCP users, create a grant with the `docker-datacenter` -> org as a subject. +> To apply permissions to all Docker EE users, create a grant with the +> `docker-datacenter` org as a subject. {% elsif include.version=="ucp-2.2" %} @@ -105,7 +106,7 @@ A common workflow for creating grants has four steps: You can create grants after creating users, collections, and roles (if using custom roles). -To create a grant in UCP: +To create a grant in the Docker EE UI: 1. Click **Grants** under **User Management**. 2. Click **Create Grant**. @@ -116,8 +117,8 @@ To create a grant in UCP: 4. Click **Create**. > By default, all new users are placed in the `docker-datacenter` organization. -> To apply a grant to all UCP users, create a grant with the `docker-datacenter` -> org as a subject. +> To apply permissions to all Docker EE users, create a grant with the +> `docker-datacenter` org as a subject. {% endif %} {% endif %} diff --git a/deploy/rbac/usermgmt-recover-password.md b/deploy/rbac/usermgmt-recover-password.md index 9692ae3864..f364374389 100644 --- a/deploy/rbac/usermgmt-recover-password.md +++ b/deploy/rbac/usermgmt-recover-password.md @@ -15,9 +15,9 @@ ui_tabs: ## User passwords -UCP administrators can reset user passwords managed in UCP. +Docker EE administrators can reset user passwords managed in the Docker EE UI: -1. Log in with administrator credentials to the UCP web UI. +1. Log in with administrator credentials to the Docker EE UI. 2. Click **Users** under **User Management**. 3. Select the user whose password you want to change. 4. Select **Configure > Security**. @@ -25,12 +25,12 @@ UCP administrators can reset user passwords managed in UCP. Users passwords managed with an LDAP service must be changed on the LDAP server. -![](../images/recover-user-password-1.png){: .with-border} +![](../images/recover-a-user-password-1.png){: .with-border} ## Administrator passwords Administrators who need a password change can ask another administrator for help -or use **ssh** to log in to a manager node managed by UCP and run: +or use **ssh** to log in to a manager node managed by Docker EE and run: ```none {% raw %} diff --git a/deploy/rbac/usermgmt-sync-with-ldap.md b/deploy/rbac/usermgmt-sync-with-ldap.md index 11ea60e706..ea698afad6 100644 --- a/deploy/rbac/usermgmt-sync-with-ldap.md +++ b/deploy/rbac/usermgmt-sync-with-ldap.md @@ -14,17 +14,17 @@ ui_tabs: {% if include.ui %} {% if include.version=="ucp-3.0" %} -To enable LDAP in UCP and sync to your LDAP directory: +To enable LDAP in the Docker EE UI and sync to your LDAP directory: 1. Click **Admin Settings** under your username drop down. 2. Click **Authentication & Authorization**. 3. Scroll down and click `Yes` by **LDAP Enabled**. A list of LDAP settings displays. 4. Input values to match your LDAP server installation. -5. Test your configuration in UCP. -6. Manually create teams in UCP to mirror those in LDAP. +5. Test your configuration in the Docker EE UI. +6. Manually create teams in the Docker EE UI to mirror those in LDAP. 6. Click **Sync Now**. -If UCP is configured to sync users with your organization's LDAP directory +If Docker EE is configured to sync users with your organization's LDAP directory server, you can enable syncing the new team's members when creating a new team or when modifying settings of an existing team. @@ -33,7 +33,9 @@ For more, see: [Integrate with an LDAP Directory](../../datacenter/ucp/2.2/guide ![](../images/create-and-manage-teams-5.png){: .with-border} ## Binding to the LDAP server -There are two methods for matching group members from an LDAP directory, direct bind and search bind. + +There are two methods for matching group members from an LDAP directory, direct +bind and search bind. Select **Immediately Sync Team Members** to run an LDAP sync operation immediately after saving the configuration for the team. It may take a moment @@ -46,7 +48,8 @@ of a group in your organization's LDAP directory. The team's membership will by synced to match the membership of the group. - **Group DN**: The distinguished name of the group from which to select users. -- **Group Member Attribute**: The value of this group attribute corresponds to the distinguished names of the members of the group. +- **Group Member Attribute**: The value of this group attribute corresponds to + the distinguished names of the members of the group. ### Match Search Results (Search Bind) @@ -55,25 +58,29 @@ This option specifies that team members should be synced using a search query against your organization's LDAP directory. The team's membership will be synced to match the users in the search results. -- **Search Base DN**: Distinguished name of the node in the directory tree where the search should start looking for users. -- **Search Filter**: Filter to find users. If null, existing users in the search scope are added as members of the team. -- **Search subtree**: Defines search through the full LDAP tree, not just one level, starting at the Base DN. +- **Search Base DN**: Distinguished name of the node in the directory tree where + the search should start looking for users. +- **Search Filter**: Filter to find users. If null, existing users in the search + scope are added as members of the team. +- **Search subtree**: Defines search through the full LDAP tree, not just one + level, starting at the Base DN. {% elsif include.version=="ucp-2.2" %} -To enable LDAP in UCP and sync team members with your LDAP directory: +To enable LDAP in the Docker EE UI and sync team members with your LDAP +directory: 1. Click **Admin Settings** under your username drop down. 2. Click **Authentication & Authorization**. 3. Scroll down and click `Yes` by **LDAP Enabled**. A list of LDAP settings displays. 4. Input values to match your LDAP server installation. -5. Test your configuration in UCP. -6. Manually create teams in UCP to mirror those in LDAP. +5. Test your configuration in the Docker EE UI. +6. Manually create teams in the Docker EE UI to mirror those in LDAP. 6. Click **Sync Now**. -If UCP is configured to sync users with your organization's LDAP directory -server, you can enable syncing the new team's members when -creating a new team or when modifying settings of an existing team. +If Docker EE is configured to sync users with your organization's LDAP directory +server, you can enable syncing the new team's members when creating a new team +or when modifying settings of an existing team. [Learn how to sync with LDAP at the backend](../configure/external-auth/index.md).