LDAP configuration for a Model Manager server using Apache Directory Studio

问题描述

I want to configureExternal Authenticationfor a Model Manager server using Lightweight Directory Access Protocol (LDAP) authentication, to allow users to log in with their domain accounts, but it's not clear how to fill in theLDAP Login Moduleconfiguration fields.

解决方法

TheLDAP Login Module, as anExternal Authenticationconfiguration for a Model Manager server, works by verifying the given username and password against user credentials stored in an LDAP directory, for example Windows Active Directory.

This solution shows how to specify the configuration settings for theLDAP login moduleusing the freeApache Directory Studio™tool to prepare the configuration. Further information is available in the Model Manager Server Manual page forExternal Authenticationand the Java® documentation forLdapLoginModule.

Using Apache Directory Studio to prepare the configuration

Setting up Apache Directory Studio

1. Download a suitable Apache Directory Studio archive fromhttps://directory.apache.org/studio/downloads.htmland extract it to some convenient location on your computer.
2. Download a Java 11 runtime archive, for example fromhttps://adoptium.net/temurin/releases/?package=jre&version=11, and extract it within the Apache Directory Studio folder.
3. Rename the extracted Java runtime folder (inside the Apache Directory Studio folder) tojreto allow Apache Directory Studio to find it.

Connecting to the LDAP server

1. Launch Apache Directory Studio.
   • Ideally you should run Apache Directory studio on the computer where the Model Manager server is installed, so that the tool uses the same network interface as the server. If this is not possible, for example if running GUI tools is not allowed on the server computer, seeConnecting through an SSH tunnelbelow.
2. In theLDAPmenu selectNew Connection
3. In theNew LDAP Connectiondialog box:
   • Write some descriptive text for the connection in theConnection namefield, say "My Connection".
   • TheHostnamefield should be the hostname of the LDAP server. Use a fully qualified hostname if you will use SSL encryption (LDAPS), to ensure that the server identity matches its certificate.
   • ThePortfield should be the TCP port to connect to on the LDAP server. The default port number is 389 for LDAP and 636 for LDAPS, but for Windows Active Directory servers it is recommended to instead use port 3268 for LDAP and port 3269 for LDAPS to access the global catalog.
   • For theEncryption method, pick eitherNo encryption(LDAP) orUse SSL encryption(LDAPS) as these are the two methods supported by the LDAP login module. Ensure that the port number is compatible with the encryption method.
4. ClickCheck Network Parameterto verify that the LDAP server can be connected, thenNext.
   • If you get a warning about an invalid certificate due to unknown issuer, choose to trust it if it is a known self signed certificate. In this case, you might also need to perform the steps underTrusting LDAP server certificatesbelow to ensure that it is trusted by the Model Manager server.
5. Enter a username and a password for authenticating against the LDAP server. You might need to add a domain prefix (username@example.com) or suffix (EXAMPLE\username). Make a note of the username format used here, as it will be the format used for theAuthentication identityfield in theLDAP Login Moduleon theExternal Authenticationpage in the Model Manager server.
6. ClickCheck Authenticationto verify that you can authenticate, thenFinish.

Optional: Connecting through an SSH tunnel

If you run Apache Directory Studio on a different computer than the one where Model Manager server is installed, you can use an SSH tunnel to be able to connect to the LDAP server as if the tool was running on and connecting from the Model Manager server computer's network interface. This requires being able to connect to the Model Manager server computer using an SSH client with local tunneling enabled:

1. Open aCommand Prompt(Windows) orTerminal(Linux/macOS) on the computer where you will run Apache Directory Studio.
2. Runssh -L8888:ldaphostname:ldapport username@serverhostname, where 8888 is an arbitrary local port,ldaphostname:ldapportis the hostname and port of the LDAP server, andusername@serverhostnameis the hostname of the Model Manager server computer and the username to use to connect to it.
3. If the SSH connection succeeds, perform the steps underConnecting to the LDAP serverabove but fill inlocalhostasHostnamein theNew LDAP Connectiondialog box and 8888 asPort. For theEncryption method, use the same settings as you would have used if connecting directly from the Model Manager server computer.
4. The connection tolocalhost:8888will be tunneled toserverhostnamefrom which a connection toldaphostname:ldapportis made.
5. The tunnel is open as long as the SSH connection is open, so keep thesshcommand running until you are finished using Apache Directory Studio.

Tunneling the connection from the tool through the server computer is advantageous if you suspect that a firewall could block connections from the Model Manager server to the LDAP server. The blocked connection would then be detected already in theCheck Network Parameterstep, allowing you to first troubleshoot and fix the firewall configuration.

Locating the user provider folder

1. When connected to the LDAP server, go to theLDAP Browserview and expand theDITnode to browse the directory tree.
2. Locate a suitable top-level folder in the organization that contains in its subtree all of the users that should be able to log in. If users span multiple branches of the directory, pick a folder near the top of the tree to cover all locations.
3. Right-click that folder and doAdvanced>Copy URLand save this URL somewhere to use for theUser providerfield on theExternal Authenticationpage.

Generating the user filter

1. Find a typical user in the directory, who should be allowed to log in. This can be done by manually browsing, or by using theNavigate>Go to DNfeature if you know the distinguished name of the user (for exampleDN=John Smith).
2. In the list of attributes for the user, select theobjectClassattribute with valueuser.
3. Then, with Ctrl pressed, scroll down to find and select a suitable attribute containing the username of the user (for examplesAMAccountNamefor Active Directory).
4. Finally, look if there are anymemberOfattributes that represent mandatory group memberships for logging in to the server and Ctrl select them as well.
5. With all relevant attributes selected, right-click and doAdvanced>Copy AND Search Filterand save this filter somewhere to use as template for theUser filterfield on theExternal Authenticationpage.

Note:If you cannot locate a typical user in the directory, you can also try proceeding using one of these common user filters:

• Active Directory:(&(sAMAccountName={USERNAME})(objectclass=user))
• OpenLDAP:(&(uid={USERNAME})(objectClass=inetOrgPerson))

Optional: Generating filters for optional group memberships

Perform the following for any other group memberships that are not mandatory, but that you want to map to user groups for access control in the Model Manager server.

1. Similar to generating the user filter above, find a representative user that has the optional group memberships and select its attributes.
2. Generate a search filter and save it to use for theUser filterfield in additional optional LDAP login module instances on theExternal Authenticationpage.

Configuring the Model Manager server

Configuring external authentication

1. Log in to the Model Manager server web interface as a root administrator.
2. Go toAdministration>System>External Authenticationand clickEdit.
3. Add an LDAP login module and set itsControl flagtoRequisite, meaning that it is required and the authentication chain stops if this login module doesn't succeed.
4. In theUser providerfield, enter the URL copied underLocating the user provider folder above.
5. In theUser filterfield, enter the search filter copied underGenerating the user filterbut replace the real username in this search filter with the string token{USERNAME}. For example, if the copied search filter is(&(objectClass=user)(sAMAccountName=john)), write(&(objectClass=user)(sAMAccountName={USERNAME})). The LDAP login module will replace the token with the username of the user trying to log in when searching for user credentials.
6. In theAuthentication identityfield, enter the username format you used underConnecting to the LDAP serverbut replace the real username with the string token{USERNAME}. For example, if you log in aszoe@example.com, write{USERNAME}@example.com. The LDAP login module will replace the token with the username of the user trying to log in when authenticating against the LDAP server.
7. If you used encryption in Apache Directory Studio, as will be seen by the user provider URL starting withldaps://, leaveUse SSLset toEnabled, otherwise switch it toDisabled. It's recommended to use encryption to not send usernames and password unencrypted to the LDAP server.
8. ClickTestand use a known set of user credentials to verify that the authentication works. If possible, test both with user credentials that should have access and with those that are valid but shouldn't have access.
   • If SSL is enabled and you get an exception chain ending with aSunCertPathBuilderExceptionexception with messageunable to find valid certification path to requested target, seeTrusting LDAP server certificatesbelow to ensure that the server certificate is trusted.
9. ClickSaveand verify that users can log in.

Optional: Mapping a default Model Manager user group

Perform these steps if you want all users logging in with the external authentication configuration entered inConfiguring external authenticationto be assigned a specific Model Manager user group.

1. Edit the external authentication configuration and fill in a unique identifier for the group to assign in theAuthorization identityfield. For example, if the group is calledengineeringyou can fill inengineering-user-group.
2. Add a group mapping with thePrincipal nameset to the unique identifier (for exampleengineering-user-group) and a mapped group withGroup Nameengineering.
3. Save the configuration, and verify that a user logging in using the external authentication has the mapped group show up on theMy Accountpage (available in theAccountmenu in the top right corner of the Model Manager server web page).

Optional: Mapping optional Model Manager user groups

Perform these steps if you generated search filters underGenerating filters for optional group membershipsabove and want to use them to map optional external group memberships to Model Manager server user groups.

1. Edit the external authentication configuration and add another LDAP login module. Set theControl flagtoOptional, meaning that authentication can succeed even if this module fails.
2. Fill inUser providerandAuthentication identityusing the same values as underConfiguring external authenticationabove.
3. Fill in theUser filterfield using the search filter for the optional group memberships, replacing the username with{USERNAME}as before.
4. Fill in theAuthorization identitywith a unique identifier for the optional group membership.
5. Add another group mapping for the optional group member ship, using the unique identifier asPrincipal nameand the optional user group name asGroup Name, similar to the instructions underMapping a default Model Manager user groupabove.
6. ClickTestto verify that the optional group is mapped if the user has a membership for it in the directory.
7. Repeat for any other optional user groups.
8. Save the configuration and verify that the optional user group mapping works.

If needed: Server certificate management

Trusting LDAP server certificates

If needed, follow the instructions below, based on the operating system that the Model Manager server is installed for, to ensure that the certificate of the LDAPS server is trusted by the Model Manager server.

You will first need to determine the root of the certificate chain of the LDAPS server, which will typically be a local CA certificate of your organization. If you don't already have it available as a file, seeRetrieving the certificate chain of an LDAPS serverbelow.

The certificate to trust can be put in any temporary location on the computer that runs the Model Manager server. After the certificate has been imported into the trust store, as described below, the certificate file is no longer used and can be removed from the temporary location.

On Windows (with a Model Manager server of version 6.2 and above)

Starting with version 6.2, the Model Manager server uses the built-in trust store of the Windows operating system so all you have to do is to import the root certificate into the Windows trust store.

1. Launch the built-incertlm.msctool in Windows and navigate to theTrusted Root Certification Authorities>Certificatesfolder.
2. From theActionmenu, chooseImportand clickNextto specify the file to import.
3. ClickBrowseor type the path to the certificate to import as a trusted root.
4. ClickNext,NextandFinish, and verify that the certificate appears in the list.

On Linux® and macOS, or Windows (with a Model Manager server of version 6.1 and below)

On Linux and macOS systems (and prior to COMSOL version 6.2 also on Windows systems), the Model Manager server uses the trust store that comes with the Java runtime in the installation.

1. Find the path to the Javakeytoolthat is included in the Model Manager server installation.
   • On Linux systems, the default path is/usr/local/comsol62/modelmanagerserver/java/glnxa64/jre/bin/keytool.
   • On macOS systems, the default path is/Applications/COMSOL62/ModelManagerServer/java/maci64/jre/bin/keytool
   • On Windows systems, the default path isC:\Program Files\COMSOL\COMSOL62\ModelManagerServer\java\win64\jre\bin\keytool.exe
   • Replaceglnxa64andmaci64withglnxarm64andmacarm64, respectively, on ARM64 based platforms.
2. Runkeytoolwith arguments-importcert -cacerts -file myrootcert.pem -alias myrootcert, where the-fileargument should point to the root certificate to import and-aliasis the alias of the imported root certificate entry in the trust store.
   • You need to run the command with permissions to write to the installation directory.
   • The alias used must be unique within the keystore and does not have to match the filename. If you want to import multiple root certificates, pick a different alias for each one.
3. Enter the password of the Javacacertsfile which is by defaultchangeit.
4. Review the certificate information and answeryesif asked to import it.
   • If you get the error "Certificate not imported, alias already exists" the alias was already in use. Pick another alias, or use -delete -cacerts -alias myrootcertto delete the existing root certificate before importing the new one.
5. Restart the Model Manager server to let it use the imported certificate.

Note:There might be other COMSOL software installed on the system. Take care to locate the correct Model Manager server installation and run thekeytoolfrom the Java runtime of that installation. In particular, there's no need to trust the server certificate for the LDAP server in a COMSOL Multiphysics installation.

Retrieving the certificate chain of an LDAPS server

The Javakeytoolis included in the Model Manager server installation, at the default paths given above underTrusting LDAP server certificates.

1. Runkeytoolwith arguments-printcert -rfc -sslserver hostname:port, wherehostname:portis the hostname and secure port of the LDAPS server.
   • If you get the error "No certificate from the SSL server", check that the hostname is correct and withoutldaps://prefix and that the port is the secure LDAPS port and not for example the non-secure LDAP port of the server.
2. The output should be blocks start start with-----BEGIN CERTIFICATE-----and end with-----END CERTIFICATE-----. Copy the last such block printed to the clipboard, which should typically correspond to the root of the certificate chain.
3. Paste the block in a text editor and save the file asmyrootcert.pemto any temporary location.

Note:You should ensure that your connection to the LDAPS server is on a trusted network, as you could otherwise in theory retrieve the certificate chain from a malicious party in a man-in-the-middle attack. To reduce the risk of such an attack you should communicate with the server administrator over a trusted channel, after retrieving the certificate chain, to verify the root certificate fingerprint before trusting it.

按类别浏览

错误消息 (65)
导入 (10)
几何 (14)
物理场 (10)
求解器 (36)
安装 (41)
网格 (14)
通用 (36)
结构力学 (2)
流体动力学 (1)
后处理 (4)
导出 (1)
绘图 (1)
产品信息 (6)
多物理场 (1)
用户模型 (1)
电磁学 (1)