ldap
from the Add provider selector to display the initial Required Settings screen.Active Directory
Red Hat Directory Server
Tivoli
Novell eDirectory
Other
and coordinate with your LDAP Administrator to provide values for the required fields:
Username LDAP attribute
Name of the LDAP attribute that will be mapped to the username. Active Directory installations may use cn
or sAMAccountName
. Others often use uid
.
RDN LDAP attribute
Name of the LDAP attribute that will be used as the RDN for a typical user DN lookup. This is often the same as the above “Username LDAP attribute”, but does not have to be. For example, Active Directory installations may use cn
for this attribute while using sAMAccountName
for the “Username LDAP attribute”.
UUID LDAP attribute
Name of an LDAP attribute that will be unique across all users in the tree. For example, Active Directory
installations should use objectGUID
. Other LDAP vendors typically define a UUID attribute, but if your
implementation does not have one, any other unique attribute (such as uid
or entryDN
) may be used.
User Object Classes
Values of the LDAP objectClass
attribute for users, separated by a comma. This is used in the search term for looking up existing LDAP users, and if read-write sync is enabled, new users will be added to LDAP with these objectClass
values as well.
Connection URL
The URL used to connect to your LDAP server. Click Test connection to make sure your connection to the LDAP server is configured correctly.
Users DN
The full DN of the LDAP tree–the parent of LDAP users. For example, 'ou=users,dc=example,dc=com'
.
Authentication Type
The LDAP authentication mechanism to use. The default is simple
, which requires the Bind DN and password of the LDAP Admin.
Bind DN
The DN of the LDAP Admin, required to access the LDAP server.
Bind Credential
The password of the LDAP Admin, required to access the LDAP server. After supplying the DN and password, click Test authentication to confirm that your connection to the LDAP server can be authenticated.
username
mapper sets the Workbench username from the LDAP attribute configured.
user-attribute-ldap-mapper
)
Maps LDAP attributes to attributes on the Workbench user. These are the default mappers set up in the initial configuration.
FullName Mapper (full-name-ldap-mapper
)
Maps the full name of the user from LDAP into the internal database.
Role Mapper (role-ldap-mapper
)
Sets role mappings from LDAP into realm role mappings. One role mapper can be used to map LDAP roles (usually groups from a particular branch of an LDAP tree) into realm roles with corresponding names.
Multiple role mappers can be configured for the same provider. It’s possible to map roles to a particular client (such as the anaconda-deploy
service), but it’s usually best to map in realm-wide roles.
Hardcoded Role Mapper (hardcoded-ldap-role-mapper
)
Grants a specified role to each user linked with LDAP.
Hardcoded Attribute Mapper (hardcoded-ldap-attribute-mapper
)
Sets a specified attribute to each user linked with LDAP.
Group Mapper (group-ldap-mapper
)
Sets group mappings from LDAP. Can map LDAP groups from a branch of an LDAP tree into groups in the Anaconda Platform realm. It will also propagate user-group membership from LDAP. We generally recommend using roles and not groups, so the role mapper may be more useful.
Drop non-existing groups during sync
. If this setting is turned on, existing groups in Workbench Authentication Center will be erased.msad-user-account-control-mapper
)
Microsoft Active Directory (MSAD) specific mapper. Can tightly integrate the MSAD user account state into the platform account state, including whether the account is enabled, whether the password is expired, and so on. Uses the userAccountControl
and pwdLastSet
LDAP attributes.
For example if pwdLastSet
is 0
, the user is required to update their password and there will be an UPDATE_PASSWORD
required action added to the user. If userAccountControl
is 514
(disabled account), the platform user is also disabled.
role-ldap-mapper
type:
ae-deployer
will map to the role of the same name in Anaconda Platform.
anaconda-enterprise-anaconda-platform.yml
configmap.
EXAMPLE: To give users in the LDAP group “Workbench”, and users with the LDAP-synced role “Publisher”,
permission to deploy apps, the deploy section would look like this:
CAFILE.cert
with your CA certificate file:
LDAPS.jks
file.CERT.pem
with the server’s certificate, CERT-KEY.pem
with the server’s key,
PKCS-CHAIN.p12
with a temporary file name, and CA-CHAIN.pem
with the trust chain file (up to
the root certificate of your internal CA).
base64
:
data
section of the secrets-exported.yml
file.
LDAPS.jks
entry has been added to the secret:
auth.https.truststore
configuration key to /etc/secrets/certs/ldaps.jks
, and auth.https.truststore-password
to the matching password. For example, after editing, it should resemble the following:
auth
service:
JAVA_OPTS
key/value: