...
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 | 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 is typical. This depends on what the running JVM has been configured to support. | NO | “jks” - but only when a ldap.truststorePath is present. | When configuring LDAP Group-limited Access, ALL of the following must be provided: | ldap.groupSettings.dn
| Distinguished Name for where to start looking for LDAP Group instances | NO - YES if intending to limit access to a Group | ou=MYTEAMS,dc=MYCOMPANY,dc=MYCOM | ldap.groupSettings.ou
| A string within an OU value that identifies a Group instance | NO - YES if intending to limit access to a Group | MYTEAMS | ldap.groupSettings.name
| a common name value that indicates the team of Syndeia Users | NO - YES if intending to limit access to a Group | MYSYNDEIAUSERGROUP | ldap.groupSettings.bindAttribute
| the LDAP attribute in a group instance that identifies the common name | NO - YES if intending to limit access to a Group | cn | ldap.groupSettings.memberAttribute
| the LDAP attribute in a group instance that identifies one or more member entries | NO - YES if intending to limit access to a Group | member or uniqueMember |
|
Operation
Restart the web-gateway service
sudo systemctl restart sc-web-gateway
...
Open a modern web browser (Chrome, Edge, Safari) and visit http:SYNDEIA.MYCOMPANY.MYCOM:MYSYNDEIAPORT/login
or https:SYNDEIA.MYCOMPANY.MYCOM:MYSECURESYNDEIAPORT/login
In the Login Form dialog, enter the LDAP user credentials for an existing LDAP user that is within the ldap.baseDN
tree or within the ldap.groupSettings.name
LDAP Group (if group-limited LDAP access was configured)
Choose LDAP from the Account chooser
Panel |
---|
panelIconId | 1f926-200d-2642-fe0f |
---|
panelIcon | :man_facepalming: |
---|
panelIconText | 🤦♂️ |
---|
bgColor | #DEEBFF |
---|
|
If an LDAP user in the proper LDAP scope cannot authenticate into Syndeia, re-confirm with an LDAP search utility that the configuration of Syndeia is correct. Verify this yourself. Usually, either the user is using the wrong user name or wrong password or the LDAP repository has a different tree structure than is assumed. |
When a user authenticates via LDAP with the into Syndeia client, it should automatically create Syndeia will create Just In Time an account with default rudimentary user read-level permissions , ie: you can open a project and read information but not create new connections, repositories, or projects- if the account is not already present.
When a user requires more permissions, use the User Management feature in the Web Admin Portal to change this.