Microsoft AD LDAP configuration issues - not working for nested groups / CNs, but working for a single CN / Container / Group with only user's inside

problem

I have got everything else working and tested, however I'm struggling with some of the functionality specifically related to user authentication.

In it's current state, it is working with authentication when I specify a single CN for the Ldap search group principle, but if I specify an AD Security Group /CN that contains additional CNs (three AD Security groups in this case), cloudstack does not return anything when I use the cloudmonkey command 'list ldapusers'.

I am using manual import mode for Microsoft AD - so I can manually import specific user's from within the CN named below.

I have verified everything is working on the AD side, and even using ldapsearch installed on the management server I can query the AD group and get all of the user's back correctly.

I have enabled nested groups within Global Settings > Access > LDAP and can confirm everything is working when I specify a single CN (I have tested all three that are within the group I'm attempting to use as the ldap.search.group.principle) - these 3 CN's only contains users, and do not contain any other CN's or groups or similar.

Here's my current settings:

ldap.basedn = DC=ads,DC=ntu,DC=ac,DC=uk
ldap.bind.password = REDACTED
ldap.bind.principal = CN=REDACTED,CN=Users,DC=ads,DC=ntu,DC=ac,DC=uk
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 = true
ldap.provider = microsoftad
ldap.read.timeout = 1000
ldap.request.page.size = 1000
ldap.search.group.principle = CN=CloudstackUsers,CN=Users,DC=ads,DC=ntu,DC=ac,DC=uk
ldap.user.memberof.attribute = memberof
ldap.user.object = user
ldap.username.attribute = SAMAccountName

I have also tried to change ldap.group.object to groupOfUniqueNames , and ldap.user.memberof.attribute to memberOf. The list ldapusers cloudmonkey command still works with these settings, and returns users, but like before - only when a CN which has no nested group memberships is used for ldap.search.group.principle

The CN/Security Group in AD Group scope is set to 'Domain local', while the Groups within this are all set as 'Universal' - could this be a potential cause?

I also get no meaningful logs within '/var/log/cloudstack/management/management-server.log', I just get "2025-01-24 11:21:50,833 DEBUG [o.a.c.l.LdapContextFactory] (qtp1473611564-19:ctx-cb3f63e9 ctx-b55043b5 ctx-db6c3fa8) (logid:3e0ab5b3) initializing ldap with provider url: ldap://REDACTED.ads.ntu.ac.uk:3268
2025-01-24 11:21:51,204 TRACE [o.a.c.a.c.LdapListUsersCmd] (qtp1473611564-19:ctx-cb3f63e9 ctx-b55043b5 ctx-db6c3fa8) (logid:3e0ab5b3) returning unfiltered list of ldap users"

Please can you advise on the correct settings to use? I get the correct output when I run the following command on the Cloudstack management host, although I expect ldap-utils isn't explicitly used by Cloudstack itself, as I had to install it on the host first:

"ldapsearch -H ldap://REDACTED.ads.ntu.ac.uk:3268 -D "CN=REDACTED,CN=Users,DC=ads,DC=ntu,DC=ac,DC=uk" -W -b "DC=ads,DC=ntu,DC=ac,DC=uk" "(memberOf=CN=CloudstackUsers,CN=Users,DC=ads,DC=ntu,DC=ac,DC=uk)""

I have tried in vein to find any additional documentation on how to do this, but I can't find anything meaningful or verbose enough to describe the different attribute values.

As far as I understand, enabling nested groups should allow Cloudstack to traverse them, but I'm getting no meaningful output. I have also tried to increase the verbosity in the management-server.log by adding:

to

"/etc/cloudstack/management/log4j-cloud.xml"

But I get no additional information outputted in the management-server.log, just 'returning unfiltered list of ldap users'.

Please can you advise and assist on how I can move forward with this, and if I need to produce any additional logs/information.

versions

I am using Cloudstack with 1 management server and 3 KVM hosts, all using Ubuntu 22.04 server, currently version 4.19.1.3, installed from fresh with version 4.19.

The steps to reproduce the bug

Add ldap settings/attributes within the UI or using Cloudmonkey
Use Cloudmonkey 'list ldapusers' to return list of users
Observe no user's are returned
Change ldap.search.group.principle to a CN with no nested memberships
Use Cloudmonkey 'list ldapusers' to return list of users
Observe a list of users has been returned
Be confused as to why nested CNs are not working for ldap search group principle and do not return any users
...

What to do about it?

Please can you advise and assist on how I can move forward with this, and if I need to produce any additional logs/information - I believe I have set all the ldap attributes correctly, as it works for CNs without any nested groups, but if a CN is selected that has other CNs inside, ldap user's are not observed.

Thanks for opening your first issue here! Be sure to follow the issue template!

Just to update this, I have set the AD Group CloudstackUsers to scope 'Universal', and this hasn't changed anything - cloudmonkey list ldapusers still doesn't return anything.

Seems like the nested groups functionality is not working at all with the current settings.

Just to add, we have reproduced this as well on 4.19.1. I hadn't reported it yet because I wasn't sure if it was just an issue with our configuration or not.

Just to update this further, I followed the upgrade process as noted here:

https://docs.cloudstack.apache.org/en/4.20.0.0/upgrading/upgrade/upgrade-4.19.html

I successfully upgraded the entire cluster to CloudStack 4.20.0 from 4.19.1.3 , running all on Ubuntu Server 22.04.5.

However, this has made no difference.

Setting the ldap.search.group.principle back to CN=CloudstackUsers,CN=Users,DC=ads,DC=ntu,DC=ac,DC=uk , and running Cloudmonkey list ldapusers returns zero results.

Nested groups is enabled, and using ldapsearch manually I can verify that I can retrieve all the members of the CloudstackUsers CN and the nested members of the CNs within, so not sure what else to try here.

Any troubleshooting steps I can do, or ways I can bottom out this issue?

I can reproduce this issue consistently. CloudStack is not using the 'memberOf:1.2.840.113556.1.4.1941' when the 'ldap.nested.groups.enable' is set to 'true'

2025-09-19 07:55:06,636 DEBUG [o.a.c.l.ADLdapUserManagerImpl] (qtp2038105753-3697:[ctx-8fdbc05e, ctx-8967c294]) (logid:e13a9f64) adding search filter for 'CN=cloudstack-users,CN=Users,DC=jithinraju,DC=in', using 'memberOf'

select name,value from configuration where name like '%ldap%';
+------------------------------+------------------------------------------------------+
| name                         | value                                                |
+------------------------------+------------------------------------------------------+
| ldap.basedn                  | DC=jithinraju,DC=in                                  |
| ldap.bind.password           | DcpBIGUMfwEpixRitIagJ13hEDOlPJ12IOUf5cury3dotb8cVOOM |
| ldap.bind.principal          | CN=Administrator,CN=Users,DC=jithinraju,DC=in        |
| 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    | true                                                 |
| ldap.provider                | microsoftad                                          |
| ldap.read.timeout            | 1000                                                 |
| ldap.request.page.size       | 1000                                                 |
| ldap.search.group.principle  | CN=cloudstack-users,CN=Users,DC=jithinraju,DC=in     |
| ldap.truststore              | NULL                                                 |
| ldap.truststore.password     | NULL                                                 |
| ldap.user.memberof.attribute | memberOf                                             |
| ldap.user.object             | user                                                 |
| ldap.username.attribute      | sAMAccountName                                       |
+------------------------------+------------------------------------------------------+

ldapsearch -H ldap://ad1.jithinraju.in:389  -D "CN=Administrator,CN=Users,DC=jithinraju,DC=in" -W  -b "DC=jithinraju,DC=in"  '(memberOf:1.2.840.113556.1.4.1941:=CN=cloudstack-users,CN=Users,DC=jithinraju,DC=in)'  cn
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <DC=jithinraju,DC=in> with scope subtree
# filter: (memberOf:1.2.840.113556.1.4.1941:=CN=cloudstack-users,CN=Users,DC=jithinraju,DC=in)
# requesting: cn
#

# Jithin Raju, Architecture, jithinraju.in
dn: CN=Jithin Raju,OU=Architecture,DC=jithinraju,DC=in
cn: Jithin Raju

# appusers, Users, jithinraju.in
dn: CN=appusers,CN=Users,DC=jithinraju,DC=in
cn: appusers

# vmwaremigrated, Users, jithinraju.in
dn: CN=vmwaremigrated,CN=Users,DC=jithinraju,DC=in
cn: vmwaremigrated

# Vishesh Jindal, engineering, jithinraju.in
dn: CN=Vishesh Jindal,OU=engineering,DC=jithinraju,DC=in
cn: Vishesh Jindal

# Kiran Chavala, engineering, jithinraju.in
dn: CN=Kiran Chavala,OU=engineering,DC=jithinraju,DC=in
cn: Kiran Chavala

# aduser 1, engineering, jithinraju.in
dn: CN=aduser 1,OU=engineering,DC=jithinraju,DC=in
cn: aduser 1

# aduser 2, engineering, jithinraju.in
dn: CN=aduser 2,OU=engineering,DC=jithinraju,DC=in
cn: aduser 2

# aduser 500, Architecture, jithinraju.in
dn: CN=aduser 500,OU=Architecture,DC=jithinraju,DC=in
cn: aduser 500

# search reference
ref: ldap://ForestDnsZones.jithinraju.in/DC=ForestDnsZones,DC=jithinraju,DC=in

# search reference
ref: ldap://DomainDnsZones.jithinraju.in/DC=DomainDnsZones,DC=jithinraju,DC=in

# search reference
ref: ldap://jithinraju.in/CN=Configuration,DC=jithinraju,DC=in

# search result
search: 2
result: 0 Success

# numResponses: 12
# numEntries: 8
# numReferences: 3

🐱 > list ldapusers
{
  "LdapUser": [
    {
      "conflictingusersource": "",
      "domain": "CN=Kiran Chavala,OU=engineering",
      "firstname": "Kiran",
      "lastname": "Chavala",
      "principal": "CN=Kiran Chavala,OU=engineering,DC=jithinraju,DC=in",
      "username": "kiran"
    }
  ],
  "count": 1
}

@DaanHoogland

fixed by #11696

thanks @DaanHoogland

Just to update this further, it turns out that even though my ldap config was applied globally (not linked to a domain), and when logged in with the admin account (not domain provided), it still would not enumerate users.

Once I logged into the root domain "/" at the Web UI login screen, and also applied the ldap config to the ROOT domain, users in nested groups were enumerated properly.

So, there may still be a bug here, but it works when the admin logs into the root domain and starts the manual import.

In addition, due to our AD structure being quite large, and the use of multiple AD servers, the default 'ldap.read.timeout' value of 1000 was always crashing out for us.

I had to up this to 100000 (100 seconds) whereby all results returned within ~25 seconds.

@benj-ntu

thanks for the follow-up feedback @benj-ntu . manual import was never designed to be used in any other way as by the root admin. I think we need to do some functional design if you expect something else.

Just to update this further, it turns out that even though my ldap config was applied globally (not linked to a domain), and when logged in with the admin account (not domain provided), it still would not enumerate users.

Once I logged into the root domain "/" at the Web UI login screen, and also applied the ldap config to the ROOT domain, users in nested groups were enumerated properly.

So, there may still be a bug here, but it works when the admin logs into the root domain and starts the manual import.

Navigation Menu

Repository navigation

Microsoft AD LDAP configuration issues - not working for nested groups / CNs, but working for a single CN / Container / Group with only user's inside #10278

problem

versions

The steps to reproduce the bug

What to do about it?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Microsoft AD LDAP configuration issues - not working for nested groups / CNs, but working for a single CN / Container / Group with only user's inside #10278

Description

problem

versions

The steps to reproduce the bug

What to do about it?

Activity

boring-cyborg commented on Jan 27, 2025

benj-ntu commented on Jan 27, 2025

scottsignal commented on Jan 31, 2025

benj-ntu commented on Feb 11, 2025

rajujith commented on Sep 19, 2025

weizhouapache commented on Sep 24, 2025

benj-ntu commented on Sep 4, 2026

benj-ntu commented on Sep 4, 2026

DaanHoogland commented on Sep 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions