...
| Expand |
|---|
| title | Purpose of each Syndeia Silhouette LDAP setting |
|---|
|
Setting | Purpose | Mandatory? | Typical |
|---|
ldap.hostname
| names the server that is providing the LDAP service | YES | ldap.company.com | ldap.port
| identifies the port on the LDAP server | YES | 389 or 636 | ldap.adminUserDN
| the LDAP Distinguished Name for the LDAP Administrator | Usually | cn=MYADMIN,ou=MYADMINGROUP,dc=MYCOMPANY,dc=MYCOM | ldap.adminPassword
| encrypted value of the LDAP Admin’s password | Usually | MYADMINPASS (like #$%^&*_NOSOUPFORYOU) | ldap.baseDN
| base Distinguished Name for the start of user queries | YES | ou=MYUSERS,dc=MYCOMPANY,dc=MYCOM |
|
Specify values for L4-11 in the LDAP provider section, these are the minimum required parameters and includes the LDAP:
...
hostname: FQDN of LDAP server,
port: port of LDAP server, usually 389 or 636 (TLS),
baseDN: base Distinguished Name (DN) from where to perform searches from,
adminUserDN: DN of admin user to bind to perform searches for other users,
adminPassword: password for admin user
adminUserDN & adminPassword are normally required for making the initial connection to the LDAP server before verifying the user.
In organizations where the LDAP server does not require any credentials to access it, these two fields may be left empty.
ldap.userBindAttribute: this attribute refers to the attribute that defines the username, usually "uid"
ldap.mailAttribute: the attribute that contains an RFC822-format (email-syntax) user identifier ("userPrincipalName" in MS AD, “email” in OpenLDAP)
...
ldap.userBindAttribute
| organization’s choice of LDAP attribute that uniquely identifies each user even without a full DN | YES | uid or sAMAccountName | ldap.mailAttribute
| organization’s choice of LDAP attribute that uniquely identifies each user’s Email address | YES | email or userPrincipalName | ldap.startTLS
| should Syndeia first attempt to establish an HTTPS session with the LDAP service before making queries? | YES | false for LDAP, true for Secure-LDAP | ldap.trustAllCertificates
| should Syndeia allow the LDAP service to use an untrustworthy or self-signed SSL certificate? | YES | false (production), true (testing) | ldap.truststorePath
| file location on the Syndeia server for the Java Keystore which holds public certificates that sign the public SSL certificate used by the LDAP server | NO | /opt/icx/syndeia-cloud-current/some/secure/path/to/keystore.jks | ldap.truststorePassword
| password for the JKS file at ldap.truststorePath | NO | Often it is left as “changeme” - but it should be changed when it a proper JKS keystore is being used | ldap.trustStoreType
| the type of Keystore. JKS. | NO | “JKS” - but only when a ldap.truststorePath is present. |
|
Operation
Restart the web-gateway service
sudo systemctl restart sc-web-gateway
At this point, if a user authenticates via LDAP with the Syndeia client, it should automatically create an account with default user read-level permissions, ie: you can open a project and read information but not create new connections, repositories, or projects.
When a user requires more permissions, use the User Management feature in the Web Admin Portal to change this.
