Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
benj-ntu opened this issue Jan 27, 2025 · 2 comments

Comments

@benj-ntu
Copy link

benj-ntu commented Jan 27, 2025

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

Image

Image

Image

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

  1. Add ldap settings/attributes within the UI or using Cloudmonkey
  2. Use Cloudmonkey 'list ldapusers' to return list of users
  3. Observe no user's are returned
  4. Change ldap.search.group.principle to a CN with no nested memberships
  5. Use Cloudmonkey 'list ldapusers' to return list of users
  6. Observe a list of users has been returned
  7. 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.

Copy link

boring-cyborg bot commented Jan 27, 2025

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

@benj-ntu
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant