Date
1 - 9 of 9
Reading and writing a security file [UP19 & XPA33]
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
|
|
Never mind. Got it. MGUSRDUMP.exe
|
|
jay Bhagat
Thats what I thought it should be part of the Upgrade process
|
|
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 processOnly 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 ^^
|
|
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
|
|
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.
|
|