Had a user call today for a password reset. Before doing any password resets, we have to confirm the user's identity against a security database. In this case, the user was previously with another bank and the field that normally contains a mother's maiden name instead had a keyword. A keyword the user had not used for several years and had forgotten.

I explained that, if she is unable to confirm the information that is in the database, I am not permitted to change passwords. She argued. I persisted in the security rules. I advised her that she should speak with her manager so that they can contact Security and correct the database. Once that is done, then I will be permitted to change passwords.

A piece of advice to users: when hanging up the phone, wait until you have actually set down the handset in the cradle before calling the analyst a jackass.

Last week, a user called with a Windows password issue. Actually, she said that she had been having problems with the password wherein she would call to have it reset, would signon, change her password and the at the next login not be able to log on. I had hear this story before and so I carefully went through the steps. I reset the password, had the user signon, reiterated the password complexity requirements and have her change the password.

"The password for all selected resources has been changed."

I then had her log off and log back on. When she did, the system said that she had the wrong password. I had her signon with the password I had initially given her and it allowed her on. I went through the cycle again one more time just to be sure.

Windows was lying when it said it had changed her password.

The ticket I sent up was sent back with a "are you sure she's doing it right" kind of message.

"Yes."

It came back again with a message saying "Well, make sure her passwords are synced up."

"She can't sync them up because it won't allow her to change the password."

The Function Desk then cut me out of the loop. Instead of sending it back to me, they just put it in the bypass bin, waiting for the user to get tired of waiting and call back to find out what was going on. I hate when they do that. Don't they believe me when I say I did the proper troubleshooting?

And so, today there were four more. Exactly the same thing. Windows saying the password had been changed when, in fact, it had not. In these instances, the Function Desk called the user, had them try a different password and eventually got them on, then closed the ticket.

But whether the user was able to signon with a different password or not was irrelevant to the issue. What is going on is the system is saying that the password has been changed when it has not. If the user's are using an insufficiently complex password, then the error message should say that.

This is a serious problem. I had four calls today from users with problems. And I did troubleshooting and tickets only because each user had called the Help Desk two or three times previously for password resets and then had problems. That's a dozen calls that really should have only been four. What's worse, in a month when those passwords expire, they are going to be calling back for the exact same problem. And that's just what I have seen. How many other calls to the score of other Help Desk analysts went unnoticed? How many people will only be realizing tomorrow that the password change they called for today didn't work? How many of them will be calling back again, and again, and again?


 

I simply cannot understand how it can take half an hour to change a password.

No. Literally. This user took 32 minutes to reset her password. She'd try something. it wouldn't work. She'd try soemthing else. It wouldn't work. I'd explain the password complexity rules again. She'd try something that didn't work. And this went on for a full half hour.

I change my own password every month and I haven't had a problem in nearly ten years. I change scores of password for other people and only occasionally do I have a problem and that's because they've called before and I've already given them that particular password so I have to choose something else. It take me a few seconds to figure that out and come up with something else that works.

But to take half an hour. Trying a new password every couple of seconds. Hundreds of failures, one right after another.

*shudder*

These are the people who run our banking system.


 

First off, some instruction on how to access remotely:

Users connecting to The Bank systems do so with VPN (Virtual Private Networking). They will be prompted for a password and then be prompted for a number off a secure-id token, a key-fob thing with a number that changes every 30 seconds. If all goes well, they are connected. The user will, however, sometimes receive an error that the password does not match. In most cases it is because, in fact, they have entered the wrong password. But sometimes, they receive the same error message because there is something wrong with the secure-id token. It could be that it has gotten suspended due to too many invalid inputs. It could be because something is wrong with the card. It could be because something is wrong with the system. In all those cases, the error is the same and there is no way for either the user or the analyst to know based on the error message or even looking at the user's profile.

And so, when the user called me this morning and said she was receiving the "wrong password" error message, I first looked at the user's profile and saw only one password violation. Users almost never receive an error once and call the Help Desk. They usually try multiple times and we usually see those multiple attempts accumulate in the password profile. With only one, I assumed that there was something wrong with the secure-id. I issued the command to clear any violations but the only way to know if that was the issue, the user would need to try again.

When the user's next attempt failed, I then followed the track that there was something wrong with the card. To do that, I must go to a weekly report and look up the user's mainframe activity there. It shows the user's activity for the previous week including logins, password changes and violations but, more importantly, it shows the serial number of their secure-id card so that I can compare it to the secure-id card they have in their hands.

It didn't match.

Problem solved. I could lift the token, that is, disable the security so that the user could get in temporarily but the user will need to contact data security to either get a new secure-id card or get the proper serial number into the security database.

The user told me that this was the first time that anyone had ever done this for her, The first time that anyone had ever investigated WHY this was a problem rather than just lifting the token since she started using VPN eighteen months ago. So, in a year and a half of using remote access, every time the user needed to signon she ended up calling the Help Desk and not one analyst took the time to actually solve the user's issue. They just lifted the token and told her to have a good day.

And it is there that is most of my daily frustration. My so-called co-workers doing a shitty job and my having to pick up the pieces.

This afternoon, I got a call from someone asking for a mainframe password reset. I saw in his profile that his password was not suspended but merely expired and talked him though the process of simply changing his password. He told me that he had been calling the helpdesk for five months and each time the analysts he talked to merely changed his password and sent him on his way. In half a year, no one took the time to let him know he could take care of it himself.

And every time this sort of crap happens, I make a note of it and when the screen fills up, I send it up to management informing them of all the ways that people aren't doing their jobs. It is a complete waste of time. The screen fills up about every two weeks so the number of mistakes remain generally consistent. My suspicion is that my efforts fall on deaf ears and nothing is actually being done about. And even if they are trying to do something about it, the stable numbers indicate that whatever they are doing, it isn't working.

I was a trainer, once. I used to be able to do something about things like this. I used to be able to help. Now, I'm just an echo, carried away on the winds of apathy.

 

User: "Well, I'll be a brunken ditch."

 

With The Bank proceeding with the process of integrating with the Other Bank that they bought with TARP funds last year, they have changed the Help Desk menu system. That is, when users call in for integration issues, there is a prompt that says "For Other Bank integration issues, press 1." The problem is, people often don't listen to the menu or just choose the first item to get a hold of someone right away. And yet, the Help Desk programmers insist on making these special rollout numbers Option 1 on the menu system.

So, I spent the last week or so keeping track of the calls coming through this line just to get an idea of how bad it was going to fail:

8 calls from users to address an integration issue chose Option 1 properly.

13 calls from Other Bank users for issues that they didn't choose the Menu 1-Integration option. That is, they chose the password menu option because they had a password issue, not specifically an integration issue in their mind but technically they probably should have chosen Option 1.

17 calls from regular Bank users calling for something completely unrelated to integration choosing Option 1 incorrectly. Often a password issue and, when not a password, usually accompanied with the statement "I don't know if this is the right menu option, but. . . "

Again, the Menu 1 option is a complete failure, by a rate of about four to one (at least, from my perspective). People who are supposed to be using Option 1 aren't. People who aren't supposed to be using Option 1 are. There is no way to derive any sort of accurate information.

I passed this information on to the programmer and he had the nerve to be surprised.

 

Geis: "Corporate Help Desk, this is Geis. Can I have you're login id, please?"

User: "Did you say Geis?"

Geis: "Yes, I did."

User: "Geis the Great?"

Geis: "I don't know how great I actually am. . . "

User: "I love talking to you when I call the help desk. You always fix everything."

Geis: "Uh. . . thanks."

User: "I only have a password issue this time, though."

Geis: "If I'm really that great, I'm sure I can handle it. Can I start with your login ID?"

 

Geis: "What sort of printer do you have?"

User: "An Exxon."

Geis: "Exxon? Do you mean Xerox?"

User: "Oh. Yea. One of those."

 

User: "Hypothetically speaking, if I were to receive emails from outside the bank that were harassing or threatening, not that that's happening, just hypothetically, would that be able to be blocked? If it were happening."

 

 2.Description:  <R> _______________________________________________
 3.                  _______________________________________________
 4.                  _______________________________________________
 5.                  _______________________________________________
 6.Appl/System:  <R> ____________
 7.Problem Code: <R> _______
 8.Ref Ticket #:     ________
 9.Review            _
10.Resolution:   <R> _______________________________________________
11.Branch #..    <C> _______

When I started at the Help Desk a decade ago, the mainframe ticket system we used had a feature where we would enter a three digit problem code and it would automatically fill in part of the ticket description line. For example, enter "101" and It would pre-fill with some text indicating that it was a mainframe password reset. As I recall, there were about 30 different things to choose from and I had a print out of the list in my cubicle.

Someone decided that these description lines were insufficient. They wanted the description line to be more descriptive of what was done. They wanted the troubleshooting steps detailed. So, the ticket page was redesigned to include three extra lines to describe troubleshooting. The problem code pre-fill feature was eliminated and people needed to fill out the entire description line from scratch. They still wanted to do some statistical analysis, however, so the problem code was retained as a line in the ticket though it was reduced to only 7 different options.

It was decided very quickly that this was also insufficient. Since everyone was entering whatever they wanted in the description line, there was no way to analyze tickets. The problem code was still there but could only be used to tell how many password resets there were. There was no ability to determine how many of what sorts of password resets there were. So, a new line was added for the application or system. This would allow us to differentiate between mainframe password resets and Novell password resets and so on. There was a list of several hundred options to enter into this field.

It was decided that this solution wasn't working because with so many choices, there was plenty of opportunities for mistakes. If one of the codes was misspelled, the statistical search couldn't register that ticket. The solution was to create a GUI, a menu integrated with the ticket system so that the proper choice could be made. This seemed to work well enough for most but for some reason the application never worked on my PC. I had to type the Appl/System code in manually and had a print out of the hundreds of choices hanging in my cubicle. This wasn't too bad for me because I always though I could type the information in faster than I could navigate the menus and there were only about a dozen or so codes that were used most of the time. I could remember those.

This went on for a while but at some point it fell out of use. I think as new PCs were swapped out, the GUI wasn't installed on the new machines or failed to function when it was installed. Since I wasn't the trainer anymore, I was no longer teaching people how to properly generate tickets and so it would seem that people were left to their own devices when filling out the Appl/System field. It took a while, but eventually this system failed as well. The field is still in the ticket, though, but what people are putting in there is anyone's guess and certainly isn't useful.

It was decided that description lines should have something to make them easy to recognize when there was a common problem. For example, if there were a lot of problems with the single signon application, it would be useful for managers to look at a screen of tickets and be able to see just how many were for single signon issues or to search for a keyword and see them. They started sending out messages that would say "For all single signon issues today, preface the description line with $SSO." This procedure grew and expanded to the point where all tickets for any single signon issue should be prefaced with $SSO and so on for a list of about 30 different descriptions.

Wait. Where did I see that number before? Sure. It was a decade ago when we used to put in a three digit problem code and have the description line automatically created.

So, I happened to talk to the Site Manager who was critiquing a printout of this list of 30 description line prefixes for people to hang in their cubicles and reminded him of the capability that we had ten years ago.

"Yea. I remember that. Whatever happened to that?"

"One of your predecessors threw it away in favor of something that didn't work. Then his successor threw that away because it didn't work either and so on up to today where you are creating another system that will not work for the same reasons that the previous ones didn't work in a futile attempt to do what we already had working ten years ago. It's the circle of life."

He then let me in on the secret that sometime in June the Help Desk will be abandoning the antiquated mainframe ticket system we have been using in favor of some Windows-based system currently being used by the bank we bought last year.

"Oh, really? This is the first I've heard of that."

The surprised look on his face told me that somehow he had assumed that that piece of information had been communicated to everyone.

I, of course, wasn't surprised.