Keeping Client Passwords in sync between servers

[Kaveenga]

Hi

Need some advice.

We now have a multi (4) server environment, and I'm seeking best/proven practice to keep the client passwords in sync between the 4 servers.

I currently have an overnight chore which outputs the clients, groups, and other security settings from the primary server to a txt file, and then executes processes on the other servers to update themselves. This works fine for security data and ClientProperties except passwords.

In version 9 I used to be able to copy the encrypted password text and paste it in another server and it worked. However, in 9.5.1 this no longer works, probably due to unicode.

Any solutions, pointers much appreciated.

Kind regards

Kavee

[Martin Ryan]

What about using integrated login, so you don't even required passwords.

[declan.rodger]

You could have a TM1 Chore or Windows Scheduled Task initiate a batch file that would transfer the ClientProperties.cub from one Server to the others.

This would however require that the other servers were stopped and started for them to start utilising the new Client Passwords, a NetStop and Start could also be initiated overnight through a scheduled task (assuming there is a time at night when no one uses the service and that you have full privileges otherwise you could end up in an endless battle trying to get your IT department to understand the requirement/concept.)

[lotsaram]

I would go with the suggestion of using integrated login and do away with TM1 passwords for end users alltogether. (You could also use CAM to keep things in sync but from what I have seen it's a right PITA compared to integrated login.)

For other methods the suggestion of a master }ClientProperties cube and syncing the entire cube is unfortunately the only viable alternative. I have tried in the past to export out the }ClientProperties cube as a text file. The export is fine, the problem is that on import the encryption algorithm will have converted some entered characters into non-printable ASCII characters that TI will interpret as file termination characters if the password field is read on the way back in (you will fine the processing will abruptly terminate when the first password containing the file terminator character is encountered.) The same issue occurs if you export the encrypted password field into a relational table and read back out or if you try to read directly with ODBO. You can open a text dump directly in Excel and DBSS the encrypted string straight into the client properties cube but this strikes me as being a non viable solution for any IT shop.

[David Usherwood]

Bit artificial - but what about converting the encrypted password into numeric format using CODE, output to file, then reassemble with CHAR?

[lotsaram]

Bit artificial - but what about converting the encrypted password into numeric format using CODE, output to file, then reassemble with CHAR?

Doable, but your would have to do this in an external program that won't have a fit when a file termination character is encountered, TI is not an option due to the issue already mentioned.

Possibly it is fixed in 9.5.2 but the last time I tried to substring the encrypted password field with a rulein 9.5.1 it reliably crashed the server as soon as a view was refreshed that contained a rule derived value that had anything to do with a password field that contained a file terminator (that is Long(pwd) is OK but SubSt(pwd) will bring down the server if it contains such a character. So rules are no good either.

[Kaveenga]

Thanks all for your suggestions.

Intergrated login is not an option yet as the TM1 servers and client PC are held in 2 seperate domains, and TM1 can't perform cross domain authetication (or so I've been told). IBM and a couple of other consultancies looked into it and said it can't be done.

The resolution, as suggested by the forum , was to copy the clientproperties.cub treating the reporting server as the star and the other servers as planets.

Cheers

Kavee