Disabling logging in for a user

[jstrygner]

Is it possible to set in TM1, that particular user/users are unable to log in untill we let them?

I would like to know if I can set, that today only 50 of them can work, next day another 50 and so on. This would guarantee, that I do not have more than 50 users working concurrently on a particular day (yes, it's a performance issue). I would like to avoid deleting and creating them everyday or resetting/changing their passwords.

I made a test with the "Max connections" set to 0, but it does not work in my 9.4 MR1 FP1 (my user can still log in). I assume 0 means unlimited. I also did not find anything about this in documentation and on this forum.

[George Regateiro]

You could utilize the password expiration days or if you are using intergrated login modify the uniqueid so they cannot log in.

The password expiration days is not a great method since if you change it from No Expiration to 1 today it will expire tomorrow (even if the password has been active for more then a day).


I guess the bigger concern is what are the users doing on the server that would cause these type of performance slowdowns. We are on 9.4 also and regularly have over 50 users in the system without issue.

[lotsaram]

If you are doing a nightly server restart then you could just swap out the clients dimension, clientproperties and clientgroups cubes for the different user groups.

Another alternative would be to take an ASCII dump of the clientgroup assignments (or build a replica cube) and define subsets in your clients dimension. Then depending on which day it is run a TI to remove all group membership of one of the client subsets (and reassign membership for the other subset) and refresh security. A client with no group membership will not have access to any objects on the server. This should work smoothly and I think is a better solution than resetting password expiration.

Of course the real issue is why you have performance issues in the first place. 50 users doing simultaneous budget entry is not a lot by any means. Limiting user numbers is only a stopgap solution, you really need to review the set-up of the model.

[jstrygner]

Thank you for your suggestions.
I know this should not be a solution for a bad performance. I just needed to know, if I have such a back door in case I really, really need it.
Regards