benj-ntu opened a new issue, #10278: URL: https://github.com/apache/cloudstack/issues/10278
### 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.3, installed from fresh with version 4.19.0. ### 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cloudstack.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
