[kevinoconnor7]

I respectfully disagree with the Daniel's blog post. Changing a password should not inherently reset all application-specific passwords, and though he doesn't mention it, it shouldn't revoke all OAuth associations either.

Perhaps I look at it in a different view point. Application-specific passwords, username/password combo, and OAuth are all separate authentication methods. The compromise of one shouldn't necessarily compromise the others (though additions/modifications subsequent to a compromise should be suspect). When the protocol for disabling a user is that you use the reset password functionality, that's using the wrong tool for the job. This is especially true when a disable user button is quite prominent on the Google Apps admin dashboard.

I worked in a K-12 school district for a while and password resets were a fairly frequent event. We also had many other web services that used Google OAuth. I'm not sure I would be keen on having to reset all of their accounts every time they forgot their password. At least 95% of password resets I did were because of forgotten passwords (remember, Google Apps doesn't have a forgot password system) and not due to a compromise or suspected compromise.

Finally, I'm not really sure what the point of changing a user's password to disable an account is. The argument could be made that you might want access to some of their data, but there's other tools in Google Apps admin dashboard for that. Want an e-mail audit? That's there (well, it was an API when I last used the dashboard extensively). There's also tools to migrate all their Google Drive data to another user. If you have the higher end Google Apps account, then you'll have Google Apps Vault which will give admins access to almost all of the user's data even once the account is suspended.