2021-07-28 21:35:29 +00:00
---
title: Configure the Pinniped Supervisor to use Microsoft Active Directory as an ActiveDirectoryIdentityProvider
description: Set up the Pinniped Supervisor to use Microsoft Active Directory
cascade:
layout: docs
menu:
docs:
2023-08-02 15:19:47 +00:00
name: With Active Directory
2023-08-02 16:27:35 +00:00
weight: 150
2023-08-02 17:22:23 +00:00
parent: howto-configure-supervisor
2023-08-02 16:27:35 +00:00
aliases:
- /docs/howto/configure-supervisor-with-activedirectory/
2021-07-28 21:35:29 +00:00
---
2023-09-13 21:33:53 +00:00
The Supervisor is an [OpenID Connect (OIDC) ](https://openid.net/connect/ ) issuer that supports connecting
"upstream" identity providers to many "downstream" cluster clients.
2021-07-28 21:35:29 +00:00
This guide shows you how to configure the Supervisor so that users can authenticate to their Kubernetes
cluster using their identity from Active Directory.
## Prerequisites
This how-to guide assumes that you have already [installed the Pinniped Supervisor ]({{< ref "install-supervisor" >}} ) with working ingress,
and that you have [configured a FederationDomain to issue tokens for your downstream clusters ]({{< ref "configure-supervisor" >}} ).
## Configure the Supervisor cluster
2022-03-03 01:01:57 +00:00
Create an [ActiveDirectoryIdentityProvider ](https://github.com/vmware-tanzu/pinniped/blob/main/generated/{{< latestcodegenversion >}}/README.adoc#activedirectoryidentityprovider ) in the same namespace as the Supervisor.
2021-07-28 21:35:29 +00:00
### ActiveDirectoryIdentityProvider with default options
This ActiveDirectoryIdentityProvider uses all the default configuration options.
2022-05-11 18:19:08 +00:00
The default configuration options are documented in the
2023-07-31 17:06:58 +00:00
[Active Directory configuration reference ]({{< ref "../../reference/active-directory-configuration">}} ).
2021-07-28 21:35:29 +00:00
```yaml
apiVersion: idp.supervisor.pinniped.dev/v1alpha1
kind: ActiveDirectoryIdentityProvider
metadata:
name: my-active-directory-idp
namespace: pinniped-supervisor
spec:
# Specify the host of the Active Directory server.
host: "activedirectory.example.com:636"
2022-05-11 18:19:08 +00:00
# Specify the name of the Kubernetes Secret that contains your Active
# Directory bind account credentials. This service account will be
# used by the Supervisor to perform LDAP user and group searches.
2021-07-28 21:35:29 +00:00
bind:
secretName: "active-directory-bind-account"
---
apiVersion: v1
kind: Secret
metadata:
name: active-directory-bind-account
namespace: pinniped-supervisor
type: kubernetes.io/basic-auth
stringData:
# The dn (distinguished name) of your Active Directory bind account.
username: "CN=Bind User,OU=Users,DC=activedirectory,DC=example,dc=com"
# The password of your Active Directory bind account.
password: "YOUR_PASSWORD"
```
2022-05-11 18:19:08 +00:00
Note that the `metadata.name` of the ActiveDirectoryIdentityProvider resource may be visible to end users at login prompts,
so choose a name which will be understood by your end users.
For example, if you work at Acme Corp, choose something like `acme-corporate-active-directory` over `my-idp` .
2021-07-28 21:35:29 +00:00
If you've saved this into a file `activedirectory.yaml` , then install it into your cluster using:
```sh
kubectl apply -f activedirectory.yaml
```
Once your ActiveDirectoryIdentityProvider has been created, you can validate your configuration by running:
```sh
kubectl describe ActiveDirectoryIdentityProvider -n pinniped-supervisor my-active-directory-idp
```
Look at the `status` field. If it was configured correctly, you should see `phase: Ready` .
### (Optional) Configure the ActiveDirectoryIdentityProvider with custom options
You can also override the default `userSearch` and `groupSearch` options with other values.
```yaml
apiVersion: idp.supervisor.pinniped.dev/v1alpha1
kind: ActiveDirectoryIdentityProvider
metadata:
name: my-active-directory-idp
namespace: pinniped-supervisor
spec:
# Specify the host of the Active Directory server.
host: "activedirectory.example.com:636"
# Specify how to search for the username when an end-user tries to log in
# using their username and password.
userSearch:
# Specify the root of the user search.
base: "OU=my-department,OU=Users,DC=activedirectory,DC=example,DC=com"
# Specify how to filter the search to find the specific user by username.
2023-04-03 23:22:21 +00:00
# "{}" will be replaced by the username that the end-user had typed
2021-07-28 21:35:29 +00:00
# when they tried to log in.
2022-10-20 12:34:12 +00:00
filter: "& (objectClass=person)(userPrincipalName={})"
2021-07-28 21:35:29 +00:00
# Specify which fields from the user entry should be used upon
# successful login.
attributes:
# Specifies the name of the attribute in the LDAP entry whose
# value shall become the username of the user after a successful
# authentication.
username: "mail"
# Specifies the name of the attribute in the LDAP entry whose
# value shall be used to uniquely identify the user within this
# LDAP provider after a successful authentication.
2021-08-19 23:27:43 +00:00
uid: "objectGUID"
2021-07-28 21:35:29 +00:00
# Specify how to search for the group membership of an end-user during login.
groupSearch:
# Specify the root of the group search. This may be a different subtree of
# the LDAP database compared to the user search
base: "ou=Groups,DC=activedirectory,DC=example,DC=com"
# Specify the search filter which should be applied when searching for
# groups for a user. "{}" will be replaced by the dn (distinguished
2023-05-31 20:01:17 +00:00
# name) of the user entry found as a result of the user search, or by
# the attribute specified by userAttributeForFilter below.
2021-07-28 21:35:29 +00:00
filter: "& (objectClass=group)(member={})"
2023-05-31 20:01:17 +00:00
# Specify what user attribute should be used to replace the "{}"
# placeholder in the group search filter. This defaults to "dn".
# For example, if you wanted to instead use posixGroups, you
# would set the group search filter to
# "& (objectClass=posixGroup)(memberUid={})" and set the
# userAttributeForFilter to "uid".
userAttributeForFilter: "dn"
2021-07-28 21:35:29 +00:00
# Specify which fields from each group entry should be used upon
# successful login.
attributes:
# Specify the name of the attribute in the LDAP entries whose value
# shall become a group name in the user’ s list of groups after a
# successful authentication.
groupName: "dn"
2022-05-11 18:19:08 +00:00
# Specify the name of the Kubernetes Secret that contains your Active
# Directory bind account credentials. This service account will be
# used by the Supervisor to perform LDAP user and group searches.
2021-07-28 21:35:29 +00:00
bind:
secretName: "active-directory-bind-account"
```
2022-05-11 18:19:08 +00:00
More information about the defaults for these configuration options can be found in
2023-07-31 17:06:58 +00:00
the [Active Directory configuration reference ]({{< ref "../../reference/active-directory-configuration">}} ).
2022-05-11 18:19:08 +00:00
2021-07-28 21:35:29 +00:00
## Next steps
Next, [configure the Concierge to validate JWTs issued by the Supervisor ]({{< ref "configure-concierge-supervisor-jwt" >}} )!
Then you'll be able to log into those clusters as your users from Active Directory.