
Its been a while since I last updated. Interesting especially since my last post was more of a ran that never really amounted to anything. Quick updates about that since I did just start talking about it …
We elevated the issue as far as we could with no resolution. They aren’t fixing it, plain and simple. Really ball-z especially because they also have not informed the rest of their install base about the issue … not too good.
So I was pissed to say the least so I went about devising a method to free ourselves from the pesky problem of user licensing. If you don’t know, Servicom currently will only allow a certain number of concurrent users logged into the system. You have to purchase additional licenses to allow more users to login. Not giving the original developers enough credit, I thought bypassing this would be super easy … not so much.
The basic login method works as follows:
1) User logs in, the password is checked and once verified a count is done on the login table
2) If there are too many people logged in - the user can’t login
So I figure, easy, just delete people out of the login table … but not so fast. Servicom actually periodically checks that table, and if your user name and pointer to the Servicom Process don’t show up in the table, you are forced to log out.
Now when researching Proteus way back when, I found TONS of articles outlining how this is not a good way to do record protection / user log ons. Any time a user’s system crashes, that record is not removed. Locking that record or user into the system. Well Servicom was slightly smart shipping a login cleaning utility that will wipe all users out of the table.
So not being able to just remove the users outright I came up with a proof of concept for another work around. A small applet that runs constantly in the background of every users machine waiting for Servicom to launch. Once it detects a launch it will remove X number of users from the table making enough room for the new user to login. Once the user has logged in successfully the other records are returned to the table, and all is well.
Of course there are some issues with this method. Since there is the possibility that in the short amount of time a user is removed from the table Servicom may check their login. But even if this does occur, all the user has to do is hit OK to a message box and continue their work. Once they are returned to the login table (which is a matter of seconds) Servicom will stop bugging them.
This may all seem like a ton of work, but these single user licenses are EXPENSIVE. So 8 - 10 hours of development time for this little app is well worth it. Of course we haven’t implemented or developed it yet because we have enough licenses for each of our employees.
And some people may say … “Well Jordan, I hear you complain about unethical things all the time. Isn’t this shady?”
I say No, only because we’ve paid a lot of money for several years for “support” which has been absolutely worthless. Based on that and the outrageous cost for a user license, bypassing their systems are totally justified. They suck. Plain and simple. And until we are off of their product we have to live with them. Hopefully that won’t be for much longer.

But along with my little login table research I also discovered a backdoor account built into Servicom: H2_AllAcc Now since we are still using Servicom to house our customer’s information, I don’t want to divulge the “Secret Password”, but lets just say that if I have access to any terminal with a Servicom client installed I can login with Administrative rights with no knowledge of user accounts or their passwords … they don’t call it H2 All Access for nothing.
That is why the lessons from War Games should always be remembered … No backdoor passwords!!!

On a lighter note I started updating Check Jordan’s Voicemail again. Unfortunately I haven’t had any new voicemail in a while. Oh well ….
Sorry for the crappy black b/g image. It was transparent but it seems Wordpress don’t jive with PNGs. I’m to lazy to fix it so this little line is all your gonna get.