Hello 

If the same credentials work in Service Center, the issue is usually not the username/password. Check these:

• Authentication type: If your environment uses AD/LDAP/SSO, OSPTool typically requires a native OutSystems user, not a federated login.
• Password special characters: PowerShell may interpret characters like `, $, &, !, or ". Wrap the username and password in quotes.
• Correct environment: Make sure you're connecting to the correct Platform Server.
• Tool version: Verify that OSPTool matches your OutSystems Platform version.

The authentication method (SSO vs. native OutSystems user) is the most common cause when the same credentials work in the browser but fail in OSPTool.

If possible can you just let me know the below things 

• What OutSystems version are you using (11.x build)?
• Does your password contain any special characters?
• Are you logging into Service Center with an OutSystems account or via AD/SSO?
  
  
  Thanks and regards,
  Akshay Deshpande 

- We are using outsystems 11.55.84

-password does not contain special characters(I have tried quoting it anyway and didnt work)

-Access to our servicecenter is limited to SSO only. However, the account I'm using right now is a native outsystems account. I can log into "/users" for instance.

The problem we're having is that an ex-employee wrote a script for this and used a user with a password that we don't know and now we want to update the job from the script(he injected a password in jenkins which is not readable anymore). However, the user that was used by the ex-employee also isn't an SSO user but just a normal outsystems account like the one I am using right now.

And the script is still running and working as of now so the version mismatch can't be the problem either.

Hi Tiemen,

Please double check if you are using an IT user (created in Lifetime) account and not End-User account (created under /Users).  I believe OSPTool expects an IT user.


Also worth checking on the command syntax, make sure there's a space after the username before the next argument.  This is based on the placement of the back-tick after "correct-user-name" in your prompt command.  


Or try this instead:  "C:\Program Files\Common Files\OutSystems\11\OSPTool.com" /Publish "C:\LocalInstall\Test.oap" "dev-platform.ourcompany.nl" "your_local_admin_username" "your_password"

I hope this helps.

One thing that might be the cause: being able to log into /users doesn't necessarily mean the account works for OSPTool. /users is the end-user Users app, and OSPTool probably authenticates against IT users (the same ones used in Service Studio / Service Center / LifeTime). Those are separate user providers, so the same username can exist in one and not the other.

Can you check if that account can log into /ServiceCenter? If it can't, that's likely it. You'd need a native IT user with permission to publish to that environment.

This article explains the difference: https://success.outsystems.com/support/enterprise_customers/troubleshooting/understanding_the_difference_between_service_center_logins_and_users_login_it_users_vs_application_users/

Thanks for the replies! 

But unfortunately nothing has worked so far.

the 'devops' user that was being used(and is correct) by our ex-employee cannot be found in:
- "lifetime/Users_List.aspx"
- "lifetime/ServiceAccounts_List.aspx"
It can only be found in "dev-platform.ourcompany.nl/users", So is it correct to say that this is where all 'Native IT users' are shown?

@Michael de Guzman I have now checked it even more thoroughly and can 100% say that the quotations and syntax are correct. The reason it was wrong in my post was because I had to manually do it.

@Huarlem Lima To log in to our ServiceCenter, we need to log in through SSO. The new user I was using wasn't able to sign in to Servicecenter. What confuses me is that some say that I need an IT user, which I think can only sign in through SSO, and some say a 'Native Outsystems User', which is a user from /users if i understand correctly. 

For example, my own account is a IT user. If I use my own username, it will say:
"Login Error : Error logging in to 'dev-platform.ourcompany.nl': Invalid username or password. SSO login is mandatory."

what confuses me is that the original 'devops' user which is correctly working with the unfindable password, does not expect SSO. Which makes me think it is NOT a IT user.

It could also be that I'm misunderstanding what a 'native outsystems user' is.

Can somebody tell me where exactly I need to create an account that will be usable with the OSPtool without SSO?

Ok I finally solved the mystery. the 'devops' account is apparently our localadmin 'break-glass' account. Which is not what we want but at least we know why all other methods failed. All IT users need SSO to sign in and this devops account was the only one able to bypass it. The account I found in /users confusingly had the exact same username. 

I had no idea an account like this existed.

Now we just need to find a way to create another IT account that bypasses the SSO. Is there a known way of doing this?

Anyway, thanks for the help!

Hi Tiemen, glad you found it. As far as I know, the documented way to have a password-based account while the external IdP (OIDC) is active is a "local administrator" in LifeTime: User Management > Authentication Settings > Add local administrator. That's exactly the kind of break-glass account your 'devops' user seems to be.

The docs only say local administrators can log into LifeTime, so I can't say for sure a new one will work with OSPTool, but since 'devops' does, it's worth testing. Keep in mind it bypasses your IdP (no MFA or password policies), so I'd use it only for automation, with a strong secret stored in Jenkins credentials.

Hope it helps!