DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.

DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
UD : User Domain
| S.NO | DESCRIPTION | STEPS | EXPECTED RESULT | TYPE |
|---|---|---|---|---|
| 1 | UD is in LDAP- right password but user is not in cloudstack | Domain should be mapped | User should be created in cloudstack, authentication should be successful | |
| 2 | UD is in LDAP- right password and user is in cloudstack | User authentication should be successful | ||
| 3 | UD is not in LDAP but is in cloudstack- password right | User authentication should be Successful | ||
| 4 | User is disabled in LDAP but not in cloudstack | 1. Disable a User on LDAP but not in cloudstack and try logging in | Authentication failure and User gets disabled in Cloudstack as well | |
| 5 | UD is in LDAP- wrong password | 1. Try logging in with wrong password | Authentication failure | |
| 6 | UD is not in LDAP but is in cloudstack- password wrong | Authentication failure | ||
| 7 | UD is not in LDAP and not in cloudstack | Authentication failure | ||
| 8 | User is in cloudstack and LDAP but LDAP server is down | Authentication failure | ||
| 9 | Delete the user form Cloudstack and try to login | Authentication failure | ||
| 10 | Make user get locked in CS and try to login with LDAP credentials | Multiple wrong login attempts | Authentication failure | |
| 11 | Disable a user in cloudstack but not in LDAP | The account should be blocked access in Cloudstack as well - and send a notification to the Domain admin and root admin. The resources are still provisioned and running. | ||
| 12 | Import a user from LDAP and check the resource allocation | It should be same as local | ||
| 13 | Add same user in different domains and try to login with LDAP user credentials | There should be no problem | ||
| 14 | Add Max number of users to fetch(1000) | |||
| 15 | Try to change the password of a user from LDAP and try logging in with both passwords | For a limited period, both passwords will work | ||
| 16 | Add few users to a domain in cloudstack without introducing LDAP, then link that domain to LDAP . | Existing local users should not be impacted because of LDAP | ||
| 17 | Try to add a new user from CS to a domain that is linked to LDAP | Operation should fail(No new users can be added from CS side after linking that domain to LDAP) | ||
| 18 | Link an OU with nested groups to a Domain in CS | Make sure cloud admin specified the option to include nested groups | Users inside nested groups should be imported too | |
| 19 | Fire the connectDomainToLdap api with domain ID that is present in cloudstack and group/OU that is present in LDAP | Linking should be successful | ||
| 20 | Fire the connectDomainToLdap API with domain ID that is not present in cloudstack and group/OU that is present in LDAP | Error message | ||
| 21 | Fire the connectDomainToLdap API with domain ID that is present in cloudstack and group/OU that is not present in LDAP | Error message | ||
| 22 | Fire the connectDomainToLdap api with domain ID that is present in CCP and group/OU that is not present in LDAP | Error message | ||
| 23 | Try to fire the API from a User account | Error message as it is an Admin only api | ||
| 24 | Configure an AD through LDAP and check if db tables are properly populated | ldap_configuration,ldap_trust_map should be populated properly | Sanity | |
| 25 | UD is both in LDAP and cloudstack but passwords are different in each of them | Both passwords should work | ||
| 26 | Have a Domain before upgrade, try to link it to LDAP after upgrade | LDAP linking should be successful. | ||
| 27 | Upgrade from 4.2 to 4.7 | 1. Upgrade form CS 4.2 to 4.7 | Newly added DB tables should be present and working properly, LDAP configuration should be successful | |
| 28 | Upgrade from 4.2 to 4.7 | 1. In 4.2, Configure LDAP 2. Link a domain with an OU 3. Upgrade CS to 4.7 4. Check the new LDAP configuration and added changes | All the newly added changes should get adopted successfully | |
| 29 | Upgrade from 4.5 to 4.7 | Newly added DB tables should be present and working properly, LDAP configuration should be successful | ||
| 30 | Upgrade from 4.5 to 4.7 | 1. In 4.5, Configure LDAP 2. Link a domain with an OU 3. Upgrade CS to 4.7 4. Check the new LDAP configuration and added changes | All the newly added changes should get adopted successfully | |
| 31 | Check the functionality of the pop up that links Domains to the OU/groups | 1. Open the popup to link OU/group to cloudstack 2. Provide details about name,type,admin(optional) in the text fields provided 3. Save | The connectDomainToLdap API should be fired taking in the values provided | |
| 32 | Password/Domain empty | 1. Try logging in with password and Domain empty | Authentication failure | |
| 33 | Test read_timeout parameter | In global settings, search for ldap.read.timeout and assign to it a very low value(1 sec). Try logging in | Authentication failure | |
| 34 | Delete User in LDAP | Authentication failure | ||
| 35 | Change User name in LDAP | Authentication failure | ||
| 36 | Change the group name in LDAP and try logging in | Authentication failure |