For many years we have been using a procedure to copy the BSE directory to a test server and restore a copy of a recent bak of the production database to the test server.

We cannot use that procedure any more and I am wondering if it has something to do with upgrading to the latest porting set and upgrading to MS SQL 2008 R2.

Does anyone have a full understanding of how the password is stored in the msql_users file? Is it just a hash or is it encrypted?

How is the actual authentication completed? Is the string in the msql_users file just passed through to DCERPC and RPC_NET calls?

I am just trying to get back to a point were we can just copy the BSE and restore a bak file and not have to run RDBMS sessions to fix the password so we can log in.

Can anyone advise?

One thing I've seen is losing the relationship between the SQL Login and the database user when restoring the database on a different server. You may want to make sure that the SQL login still points to the correct database user. If it doesn't, you can run the following from the baandb: "sp_change_users_login 'Update_One', 'database_user', 'sql_login'" (substitute database_user and sql_login for the actual values).

If that doesn't work, what error do you get when you try to login to the test server?

Vince

I know exactly what you are referring to when talking about the loss of link between the SQL Login and the database user.

The exact reason for this is a mismatch of the SIDS for the SQL Logins. When a SQL Login is created on one server it is given a SID. When you create a new user for the database, the user is linked to the SQL Login (having that SID).

When you transfer/restore the database to another server, that server may have a SQL Login that's name exactly matches the name on the other server but the underlying SIDs do not match.

Many use the procedure of removing the "orphaned" database user and recreating that user in the baandb database.

I prefer to recreated the SQL Login with the same SID as the other server so I never have to remove and recreate the baan user.

I just want to understand how the password hash is created and what is it compared against to authorize the connection.

I have run the sessions ttdba0115m000 and ttdba0110m000 and I am sure the passwords are correct (I can log into the server using SQL Server authentication in the MSSMS without issue).

I have to take a wild guess and assume the encryption algorithm takes into account the SQL Login's SID when creating the password hash. But since it also uses something else (maybe the time?) as a salt, I can't test that guess as I have no way to run two password generation sessions at the same exact time on two different servers)

Does anyone have a full understanding of how the password is stored in the msql_users file? Is it just a hash or is it encrypted?
Encrypted.
You can try encrypt.exe command:

C:\Infor\ERPLN\bse>encrypt 12345456
l5FJ-Pt[CN(jdd\u&}b>EC^.HWNMSLo0

Encrypted.
You can try encrypt.exe command:

C:\Infor\ERPLN\bse>encrypt 12345456
l5FJ-Pt[CN(jdd\u&}b>EC^.HWNMSLo0

Thanks but we run IVc4 and this executable does not come with IVc4.

It shouldn't be a Baan IV vs LN issue. The encrypt.exe binary did not exist for Windows until recently. There is a solution to download it; unfortunately, I can't seem to pull up any results on the InforXtreme knowledgebase right now, so I can't provide the number. You should be able to do a search for encrypt and find it on the InforXtreme site.

Vince

Hi,

I'm also on IVc4 and on our system there's a encrypt6.1 within the $BSE/bin folder.

Regards
Günther

Unix porting sets have always had the encrypt6.x binary available. encrypt.exe was only made available on Windows relatively recently.

Vince