Trying to add AD identity source results in error 403

I have a new instance of morpheus which I am testing, but I am unable to add an identity source pointing to Active directory. I fill in the form to add ID source, but it always results in error from morpheus 403 dont have permission.

The user I am leveraging for this is the primary administrator account. I tried also adding user admin role to this account but still result is the same.

Is the external identity providers unavailable to community version testers?

I am loathe to invest in a POC if basic things like AD integration do not work out of the box.

I’m not sure on limitations to the community edition for IDM. How are you defining the bind user? It should only be the sAMAccount.

Example:

Strange, I filled out fields as above


And it was successful. Not sure how the error 403 permission denied error would come from this having wrong entries here, or if there was a change from yesterday to today when I logged back in. I may review the ui logs to see if anything jumps out.

On review my previous attempts to commit this dialog for AD did fail and produced consistent java exceptions - Forwarding to error page from request [/admin/userSources/save] due to exception [failed to convert to serialized Message content]

It appears that the parser for the lookup username cannot handle DOMAIN\username format. This is a bit confusing on the user end, because a 403 is usually permissions based so I was searching for a license, or tennancy based reason for the failure rather than a parsing one for the input.

"#
OOPS!

You do not have permissions to access this page

Error Code: 403"

It could be a handling on our side, but typically a binding username is only the samaccount and does not contain the domain\ or @domain. PowerShell will technically fail if you define a user.

I’m glad that you got it working however!

I am glad at the simplicity in the end. some solutions require you to enter a full on LDAP coordinate for this user which is a pain. Some simple input validation would probably be a simple fix here, which I see appearing elsewhere to great assistance.

the 403 issue happened as a result of the new Session store not being able to broadcast a temporary object or serialize it over rabbitMQ. Apologies as this is misleading and a fix is coming to 5.4.14