LDAP troubleshooting

[ffslcschools]

Are there any hidden java command line tools that can be used to step through the ldap configuration process? I am having a hell of a time getting ldap to work on a management server running Ubuntu 24.04.01 lts. I was able to get it working on a previous install running on CentOS 9.
I can see it trying and I know it is binding, but it returns no users.

[DaanHoogland]

@ffslcschools , I know its a pain and furtunately this is a one time effort, but unfortunately there is not much to help. I use apache directory studio to help checking the organisation of the ldap tree. (https://directory.apache.org/studio/). Are you using manual, auto import or auto sync?

[ffslcschools]

@DaanHoogland , to be honest I don't know, the documentation is extremely confusing in relation to all of the different management interface locations that ldap can be configured. I believe I am setup for the manual import, where I choose Add LDAP Account and then select the domain filter to have it populate accounts based on the group membership.
After all day yesterday and now this morning I finally have it returning results, I'll be damned if I know what I changed. This really needs to be outlined better in the documentation with regard to Global Settings vs Domain settings.

I guess I should create a suggestion change request what have you for the ldap process.

[DaanHoogland]

@ffslcschools documentation improvements are welcome as much as feature improvements, so yes, please do.

[ujan-shakya]

Hi @ffslcschools, I am also stuck in similar situation where no users is returning. I am using authentik for LDAP Provider. If you have any insights for this issue it will be very helpful. :)

[ffslcschools]

@ujan-shakya
I did get it working and I documented what I had done. I have been away from testing Cloudstack for a bit and just recently got back to it. Now I am back to being unable to get ldap working again no matter what I try. I constantly get the error below regardless of what certificates I put in the keystore.

Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
File permissions are set for root:cloud on the folder and keystore files so they should be accessible. I don't know if the intent is to configure LDAP in Configuration/Global Settings/Access/LDAP for the entire instance and then configure scoping from the Domains section, or if that even matters, but when I do figure out the certificate combination and am able to reproduce successful ldap setup I will reply with my settings.

[rajujith]

@ffslcschools Could you try these steps:

STEPS TO ENABLE/ADD LDAPS SERVER IN CLOUDSTACK

cd /etc/cloudstack/management/

Download the Server certificate, not the full chain or the ROOT CA certificate.

echo "" | openssl s_client -connect ad.domain.local:636 -showcerts 2>/dev/null | openssl x509 -out ad-server-certificate.pem

openssl x509 -in ad-server-certificate.pem -noout -text

Import the X509 certificate/ PEM file to a java keystore.

keytool -importcert -alias labAD -file ad-server-certificate.pem -trustcacerts -keystore ad-acs-keystore -storetype JKS
keytool -v -list -keystore ad-acs-keystore

root@mgmt1:/etc/cloudstack/management# ll ad-acs-keystore
-rw-r--r-- 1 root root 1332 Jan 27 12:32 ad-acs-keystore

Copy the keystore file to all management servers in the same path.

Update the CloudStack global configuration and add the LDAPS server.

ldap.truststore : /etc/cloudstack/management/ad-acs-keystore

ldap.truststore.password: password

Update requires service restart !

Add the LDAP servers using the CloudStack UI.

[ffslcschools]

I use a very similar process for building the keystore with the exception of the -trustcacerts option for -importcert, I did not know that you had to restart the service to get it to read the new settings, as the gui say settings will be applied within 30 seconds.

I do have it accepting the ldap server from Configuration / LDAP Configuration, it still doesnt populate the search windows for accounts like it used to though.

Can you explain the connection between Configuration / Global Settings / Access / LDAP and the settings in Domains / ROOT / subdomains which can pull the settings from Global Settings if you click the reset button but can also have different settings.

[ujan-shakya]

@ffslcschools Thank You for your reply, I will also look into it and update my progress. and would you mind sharing your previously working document? I will try working from that docs, any information is helpful :).
Just wondering.... you did get it working from the GUI itself ? or using CloudMonkey ?

[ffslcschools]

Configuration is similar to what rajujith posted above and I was focusing on the gui.

keytool-genkey -alias ldaps -keyalg RSA -keystore /etc/cloudstack/management/daps.jks -keysize 2048
keytool -importcert -file /etc/cloudstack/management/ad_certificates/.cer -keystore /etc/cloudstack/management/ldaps.jks -alias "ldaps"
chown root:cloud /etc/cloudstack/management/ldaps.jks`

I thought I was changing settings in the Domains section but now I don't know what is what. Here is what I was using in the sub domains ROOT / test, ROOT / test 1 and so on.
ldap.basedn dc=test,dc=com
ldap.bind.password
ldap.bind.principal <fully distinguished user name cn=user,dc=test,dc=com>
ldap.email.attribute mail
ldap.firstname.attribute givenname
ldap.group.object group
ldap.group.user.uniquemember member
ldap.lastname.attribute sn
ldap.nested.groups.enable on
ldap.provider microsoftad
ldap.search.group.principle <fully distinguished group name cn=groupname,dc=test,dc=com>
ldap.truststore /etc/cloudstack/management/
ldap.truststore.password
ldap.user.memberof.attribute memberof
ldap.user.object user
ldap.username.attribute samaccountname

[ffslcschools]

@ujan-shakya
Ok, I finally have things back to working at the Domain level. Global Settings are clear of any specific data other than microsoftad and the associated ldap attributes. The ROOT domain has no settings, other than a search base dn so there isn't an error when clicking on the Add LDAP Account button.
Otherwise, the settings are the same as above, I was able to point each domain to a different keystore to verify that they work although I am not 100 percent sure that it is utilizing them, I feel like the logs show that each look up tries all LDAP Configurations that are configured.
@DaanHoogland I don't know if this is something that can be changed but it would seem to me that adding a ldap source in Configuration / LDAP Configuration should have the bind server, account and key store all configured there with a test button. Once that is there and verified to be working then associate the ldap source and search filters to the different domains, or if you only want one source the Global Configuration section. I am sure there is some design reason for the way it is setup, but it is not straight forward at all.

[DaanHoogland]

@ffslcschools , the design was incremental for three types of configuration methods. I am sure improvements can be made. A test button could be nice indeed. You can create a new issue for that. It would need some more specification as to what it would do, I think. A dialog that requires all fields just to test if ACS could reach the ldap is one side, but the other aspect is retrieving all the settings to test if they all work together.
You indicate that you had to clear some setting in order to make it work. Can you expand on that part (in an issue)?

[ujan-shakya]

@ffslcschools Thank you, Yes I have also got it working. I am using another provider lldap.