Reading and writing a security file [UP19 & XPA33]


Florian Groothuis
 

Hi all,

I want to upgrade clients from uniPaaS1.9 tot XPA3.3d. The new environment has a new security file with some additional data but has no users besides Supervisor. Is there a way to read the old UP-security file (users, rights and groups) and write it to the new security file?

Thanks in advance

Florian


Florian Groothuis
 

Never mind. Got it. MGUSRDUMP.exe


jay Bhagat
 

Thats what I thought it should be part of the Upgrade process


Florian Groothuis
 

Just one minor issue: I can move the ID's, the names, the rights, but what about the passwords?...


Wes Hein
 

Just use the existing usr.eng, seems to work for me

Wes


Andreas Sedlmeier
 

On Tue, Jul 30, 2019 at 12:15 PM, jay Bhagat wrote:
Thats what I thought it should be part of the Upgrade process
Only if the format changes (like from v8 to eDeveloper). Then there's a usrupdate.exe which converts from old to new security file format and that would keep all information, including passwords,

Why this tool is not part of all Studio / Dev installations . Dont know. My guess is that it is too easy to reverse engineer in order to be able to crack any Magic security file.

I would just stay away from them ^^


Florian Groothuis
 

Normally I would use the old user file, but in the new release of our application a few new secret names were added.


Andreas Sedlmeier
 

On Wed, Jul 31, 2019 at 08:42 AM, Florian Groothuis wrote:
Normally I would use the old user file, but in the new release of our application a few new secret names were added.
Well you can use http://kb.magicsoftware.com/articles/bl_Reference/UserAdd-xpa-3x
to add the users from userdump utility to your new security file(s).

They will get a new password and you'll need to tell them. You cannot create onetime passwords.

Since this is something which basically violates all good practices and compliance I would suggest to think about AD logins resp. LDAP where you no longer have th passwords in security file. Secure names there I would not consider very secure too. Better use a secure vault or something else

Andreas


Florian Groothuis
 

LDAP has my preference, but that isn't applied in our application. So, no issue.

I decided to move the old user file to the new environment anf have our consultant enter the new secret names.