LInk Account to LDAP Improvements

[scottsignal]

ISSUE TYPE

• Enhancement Request

COMPONENT NAME

API/UI

CLOUDSTACK VERSION

4.19.1.3

CONFIGURATION

LDAP w/Active Directory

OS / ENVIRONMENT

Ubuntu 22.04

SUMMARY

This is a request for some general enhancements when linking LDAP Accounts via linkaccounttoldap

1. The GUI does not show that an account in LDAP linked at all. it would be nice to have some sort of indicator.
2. When an Account is linked to LDAP via linkaccounttoldap, you should not be able to create manual users in this account in the API or GUI. If an account is linked to LDAP, it should enforce ldap auth.
3. There is no way to fix a DN should you need to update the value without editing the database.

STEPS TO REPRODUCE

1. Just show on the account Details if the account is LDAP linked or not.
2. Don't allow new users to be created in the account after it is linked to LDAP via linkaccounttoldap.
3. Ability to update ldapdomain value on an account should it need to change

[DaanHoogland]

@scottsignal, looks like mostly sensible changes, though I had to read twice ;)

ad2; The one that I doubt is to not be able to add a manual local user to an LDAP linked account, but we can put this behind a feature flag.

ad 1; you mean outside the details (in the list overview)?

[scottsignal]

@scottsignal, looks like mostly sensible changes, though I had to read twice ;)

ad2; The one that I doubt is to not be able to add a manual local user to an LDAP linked account, but we can put this behind a feature flag.

ad 1; you mean outside the details (in the list overview)?

Apologies, I should have clarified further.

ad 2; I am fine with a feature flag (May make sense to have it at Domain level?). From a compliance standpoint we do not want someone to be able to create a local user on an account that is enabled Link to LDAP. We are doing 2FA outside of Cloudstack (via LDAP) and just want to enforce it.

ad: 1; I just was referring to the details tab under account in the GUI. This could be returned in the API as well. Currently there isn't a way to even return what accounts have LDAP enabled via API.

[bernardodemarco]

ad: 1; I just was referring to the details tab under account in the GUI. This could be returned in the API as well. Currently there isn't a way to even return what accounts have LDAP enabled via API.

@scottsignal, currently it is possible to retrieve the usersource (SAML, LDAP, or native) via the listAccounts ( see docs) and listUsers (see docs) APIs. However, the UI only displays it in the user details tab.

The #9932 ticket addresses adding a search filter to search users based on their source and displaying the source in the list view. I'll likely start working on it by the end of the week. I can also try to add the usersource search filter for accounts and display the source in both the list view and the details tab. What do you think about that?

[scottsignal]

ad: 1; I just was referring to the details tab under account in the GUI. This could be returned in the API as well. Currently there isn't a way to even return what accounts have LDAP enabled via API.

@scottsignal, currently it is possible to retrieve the usersource (SAML, LDAP, or native) via the listAccounts ( see docs) and listUsers (see docs) APIs. However, the UI only displays it in the user details tab.

The #9932 ticket addresses adding a search filter to search users based on their source and displaying the source in the list view. I'll likely start working on it by the end of the week. I can also try to add the usersource search filter for accounts and display the source in both the list view and the details tab. What do you think about that?

Actually, I think this would help with what I am looking for. I am just looking to make sure we easily have a process to Audit access. Thanks for the tidbts on the API. I missed this.

[DaanHoogland]

So remaining are two improvement requests

ad 2; this to be put behind a feature flag: As an operator I want to have the ability to disable the manual creation of native accounts and/or users in accounts and domains that are linked to LDAP.

ad3; As an operator AI want to have the ability to update ldapdomain value on an account should it need to changed.

Is this right, @scottsignal ? If so, I'd like to move this to discussions and create two separate issues/PRs for those.

cc @bernardodemarco

[scottsignal]

So remaining are two improvement requests

ad 2; this to be put behind a feature flag: As an operator I want to have the ability to disable the manual creation of native accounts and/or users in accounts and domains that are linked to LDAP.

ad3; As an operator AI want to have the ability to update ldapdomain value on an account should it need to changed.

Is this right, @scottsignal ? If so, I'd like to move this to discussions and create two separate issues/PRs for those.

cc @bernardodemarco

Yes, that is correct. In the future, I will make sure I submit things like this as separate issues.

[DaanHoogland]

Yes, that is correct. In the future, I will make sure I submit things like this as separate issues.

thanks @scottsignal , it is no big deal and it work this way so don't beat yourself up. In the furutre you could also start discussing first in a discussion thread (https://github.com/apache/cloudstack/discussions/new/choose) and find the right category, or use the mail list. Again, this is fine as well. I want to split for clarity, not because your issue is entered the wrong way.

[bernardodemarco]

@scottsignal, just letting you know that I've opened a PR (#10115) to extend the listUsers API, enabling callers to filter users by their authentication source (e.g., native, saml2, saml2disabled, and ldap). UI support has also been implemented.

On #10030 (comment), I mentioned the possibility of addressing similar behavior for the listAccounts API. However, in CloudStack, an account can be linked to users with different sources. For instance, in the following scenario, an LDAP account (gauss) was created, which automatically generated a default user. Later, a native user was added to the same account.

Since the usersource attribute is tied to users rather than accounts, it's not possible to extend the listAccounts API in the same way it was done with listUsers.

[scottsignal]

@bernardodemarco Thanks for the enhancement on #10115.

Did ad3 into its own issue? Seems like ad1 and ad2 are now addressed and this could be closed.