Kaseya Community

Harvested AD accounts can't authenticate to VSA

  • Hi Community,

    We have been using harvested AD accounts from discovery to authenticate to the VSA. It has been working fine until a few weeks back when it suddenly stopped working for most of the accounts. Trying to authenticate results in "Username or password incorrect". We raised a ticket with support but the issue has not been resolved yet. We have resorted to creating VSA local accounts for the time being but we do not want to continue like that.

    We have tried a few things to resolve the issue but none of it has helped yet. 

    • Tried to run a full synchronization on the probe
    • Tried to uninstall and detach the organization from the probe, then run a new installation and harvest
    • Tried to delete one of the accounts and recreate the VSA access via user policy

    Has anyone come across such an issue? What was your solution? Is there anything that I can try to resolve the issue while waiting for support to figure out what is wrong?

    We are currently working fine with the VSA local accounts but most of us had agent procedures in our private containers that we were working on and we desperately need those to move ahead.

  • Hey,

    I am having the same issue and when logged a call with Kaseya they say that it is an issue on the AD side, I have talked to Internal IT regarding this and I am using the same DC same everything but not resolution.

    I think that there is alot of bugs within the version .24 of Kaseya latest and hopefully they resolve most of these issues in the next release.

    What version of Kaseya are you on?

    Thanks

    Denis

  • Just a simple thing, but have you checked that the Kaseya Directory Integration Service is running on the VSA server?

  • Same thing over here and we are on SaaS.

    Not all users are affected but those that were, local account were created instead.

  • Hi Mark,

    Yes all my services are started. This issue only seems to have happened for me since I have upgraded the system to 9.5.0.24.

  • in .24 there was a bug introduced that meant any AD authenticated account with a # in the password would fail to log in.

  • This was fixed in .25

    Fixed an issue where Discovery failed to authenticate passwords that contain the # character.

    help.kaseya.com/.../RN

    Curious as to more detail as to what others are experiencing within version .25

  • Hi Jo,

    The user in the company doesnt have a # symbol in their password.

    As Chris Y said also he is in SaaS and he is having same issue and I would assume that SaaS is on latest version of Kaseya.

  • Have support tickets been created on the issue?  If so, could you provide the zendesk ticket #'s so I can have a look?

  • Hi Oscar,

    The ticket which I logged is #490479.

    I was getting no where from Support so didnt keep it opened and just created local accounts for the users which are having the issue.

    Thanks

  • Yes, it was opened on the 18th of February with ticket# 587541.

  • Thanks Denis.

    We're on SaaS and I'm pretty sure there is nothing wrong with the AD. I have tried setting a 'Create VSA User' policy for a test account from AD and run a full sync. That account managed to log in using the AD credentials.

  • Kaseya still doesn't like £ symbols in passwords though!

  • I had a user who was using the £ symbol in their password and wasn't able to log into Kaseya. Once the user removed any special characters the user was able to log into Kaseya with their harvested accounts.

    So can someone tell me what characters Kaseya doesn't like to be used in a password.

    You would think in this day and age that Kaseya would accept all characters for passwords.

  • this is from their helpdesk -

    We've had a known issue on 9.5.0.24 where in password with sql characters such as <> ' " #()& were not supported