This is fine for things your organization controls. It isn't possible when dealing with lots of outsourced services. Too few services provide a way to hook into your LDAP or Active Directory.
True, but there still shouldn't be a shared password. Personal accounts for everyone.
For the few truly top-level master accounts around, a printed password in the safe will do fine. It should be painful and feel dangerous to use those, because it is.
This isn't possible for every service. For example, our company Twitter account. Twitter doesn't allow any way for individuals to have their own passwords and post to the account. We have a social media team, all of whom need to be able to post to the Twitter account. There is no way around sharing a password for that (and it's just one example of many). It's great to be idealistic and say don't share passwords, but in the real world, it's not always possible.
If you have a good internal service for auth/z, you can store passwords for less-critical outside services in plain text files on a network filesystem, with permissions locked down so that only the relevant people can read those files. In terms of security this seems similar in strength to what Passpack does--it lets authorized users see the actual passwords if they want to, or you can build applications on top to read from the file and log in to outside services. I did something like this once for FTP-style logins, and it worked all right.
Apart from that case, you really can integrate Kerberos or similar into your own applications, using e.g. SASL.
For the few truly top-level master accounts around, a printed password in the safe will do fine. It should be painful and feel dangerous to use those, because it is.