The Titlewave of Password Changes

Here at work, we have to change our enterprise passwords every 90 days. I am sure this is similar to many institutions.

We get three warnings: one at ten days, one at six days, and a final warning at three days. That gives us two days to forget about the impending doom. Sounds like a recipe for success.

Changing our password means all saved passwords have to change; otherwise our account gets locked and we cannot log into anything. For me, locked accounts means no workie. Sounds promising, except I like to do my work and hate being frustrated with inane minutia that stretches out for hours.

Here is the list of what I have to change.

I have 5.5 devices to work with: work iMac - with virtual Windows 7 machine, Macbook Pro, iPhone, iPad, home iMac.

Work iMac
  • Initial logon
  • Email
  • Lync
  • Safari web signon password
  • Firefox web signon password
Windows 7 Virtual
  • Initial signon - thankfully this is used for other programs
  • Email
  • Internet Explorer web signon password
 Macbook Pro
  • Email
  • Lync
  • Safari web signon password
  • Firefox web signon password
  • VPN connection
  • RDP client
iPhone
  • Wireless password
  • Email password
  • Safari web signon password
iPad
  • Wireless password
  • Email password
  • Safari web signon password
Home iMac
  • Email
  • Lync
  • VPN connection
  • RDP client 
Oh, the horror. That's 24 places I have to change my password, or I might not be able to do work.

Someone get Jeff Atwood's Internet Driver's License up, quick!

Comments

Post a Comment

Popular posts from this blog

Integrated Windows Authentication with Chrome and Firefox

Image
A few days ago, the Powers That Be at my institution rolled out a change to our web authentication scheme. Previously, we were using a proprietary system that somehow played nice with Active Directory. The changed made Active Directory Federation Services play nice with our proprietary system - making ADFS do the real work. Now, we live in the world of Integrated Windows Authentication. I'm all for that, mainly because the proprietary system was a PITA in a lot of cases. This new change makes a lot of thing easier. Plus, now logging onto your workstation logs you into our webapps! Well, not for me. I use a Chrome and Firefox. Well, not yet anyway .... It works great for Safari users on a Mac. However, I use Chrome mostly and Firefox for development testing.  How on earth do I tell Chrome what servers are okay to do Microsoft Integrated Login with? I guessed there was a way to configure Chrome and Firefox to do this, and it turns out there is! However, it&
Read more

Planned System Downtime

I have some thoughts on planned downtime. Ultimately it boils down to this: is the planned downtime caused by urgent, impending, and guaranteed doom? If yes, then by all means have the downtime whenever you can. If not, affected as few customers as possible, by the numbers. Planned system downtime should minimize impact to system usage - period. By "System Usage" I mean real customers using the system. I recently had a discussion with the systems group about a necessary outage on a system I support. Something important, but not urgent had the possibility to cause downtime on the system. However, if something went wrong and we had to restart a server, the server might not come up. This was deemed as needing pretty serious attention (which I agreed with). They found a fix and wanted to put it into production, as an emergency, planned downtime. We had a downtime window coming up, but this should probably happen before the window. They suggested an evening. Google Anal
Read more

Error Handling

Image
I found this actual error message today while working with a vendor application: Okay, it wasn't that exact error message. And that's my code. BUT, the first part is verbatim. This is a server-side, vendor-provided, and above all, released product. This is not a beta; we paid someone to give us that error message. What am I supposed to do with that message. My code called your code and it told me "Unable to get resources." Guess I'll just take a nap till those resources can be gotten. Over the years I have seen both vendor applications and custom code where programmers are throwing away valuable information by not properly sending errors up the stack.   You should always, always, ALWAYS send your errors up the stack! * The error above could easily have been something like this: See, now I know something! This is a java.lang.NullPointerException exception in the file MeaningfulError.java - on line 11. That's an informativ
Read more