docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Convert UCP to Docker EE UI (#306)

This commit is contained in:
Gwendolynne Barr 2017-11-29 04:38:12 -08:00 committed by Jim Galasyn
parent 93718ce14b
commit e707cf9fd4
10 changed files with 237 additions and 90 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
_data/toc.yaml
View File

@ -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:

40
deploy/rbac/howto-wordpress-multitier.md
View File

@ -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.

12
deploy/rbac/howto-wordpress-view-only.md
View File

@ -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**.

26
deploy/rbac/index.md
View File

@ -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.

157
deploy/rbac/resources-group-resources.md
View File

@ -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/<username>`. 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

22
deploy/rbac/usermgmt-create-subjects.md
View File

@ -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**.

2
deploy/rbac/usermgmt-define-roles.md
View File

@ -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:

19
deploy/rbac/usermgmt-grant-permissions.md
View File

@ -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 %}

8
deploy/rbac/usermgmt-recover-password.md
View File

@ -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 %}

37
deploy/rbac/usermgmt-sync-with-ldap.md
View File

@ -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).