Solaris PAM (specifically pam_unix_account.so.1 I believe) requires all LDAP user entries to belong to objectClass: shadowAccount. If you have no need for user passwords in LDAP like we do, tough luck - you still need to have have this set for each user account.

If you don’t have objectClass: shadowAccount set for a user, he or she will be quietly rejected login to the host in question. Syslog will show No account present for user.

Client

1. If you have credentials for more than one Kerberos realm, make sure your Default identity (in KfW) is set to the realm you want Thunderbird to authenticate to. You can set this by right-clicking on the identity. If you change which identity is your default, restart KfW.
2. In Thunderbird, go to Options –> Advanced –> Config Editor. Toggle the value network.auth.use-sspi to false. Restart Thunderbird
3. For your account settings, you must use a fully qualified domain name (not just a host name or an IP address).

KDC

1. Add principal imap/mailserver.yourdomain.com
2. Extract imap/mailserver.yourdomain.com into mailserver.yourdomain.com’s keytab

Mail Server

1. Read and understand completely the Cyrus IMAP documentation!
2. On your mail server (where Cyrus imapd is running… which you built to support Kerberos 5 via GSSAPI…), /etc/imapd.conf cannot specify a sasl_minimum_layer as Thunderbird does not support even layer 1.
3. The relevant options I use are:
   allowplaintext: false
force_sasl_mech: gssapi
sasl_log_level: 4

Thanks to Ken Hornstein and Jeffrey Altman for their help.

Maybe see also: bugzilla.mozilla.org

Solaris Domains - What are they and how are they different from Resource Pools and other similar tech? Are they obsolete nowadays in favor of Resource Pools (Dynamic or not)?

# who -Hr
NAME       LINE         TIME          IDLE    PID  COMMENTS
   .       run-level 3  May 16 06:26     3      0  S

Running “man who” indicates -r but gives no description of the meaning of the fields’ values in this special usage (like “the comments field indicates the last run level used”… or what the IDLE value indicates).

RHEL v4 (GNU coreutils)

# who -Hr
NAME     LINE         TIME         IDLE          PID COMMENT
         run-level 3  Apr 12 10:22                   last=S

That’s bettter! last=S is a little more intuitive. Running “man who” indicates -r then suggests reading ‘info coreutils who’ for more information on the who command. Running ‘info coreutils who’ brings up the GNU info page and it completely omits mentioning the -r option or its meaning.

Sweet.

Horseshit. Fix the damn code. And no, it was not my bug report.

1. Your new Solaris patching system is 90% sucky for paid customers and 100% awesome for you
2. The host sunsolve.sun.com is always sluggish or downright slow
3. The host osc-amer.sun.com is always slow (for years now). I’ve spent the last 30 minutes watching my support request form submittal time out. It’s not the first time.
4. Your documentation quality has gotten significantly poorer over time

1. The now-defunct shareware editor “Lemmy” which I’d licensed
2. The port of Elvis to Windows
3. and finally, when I’ve been able to tolerate it for very long, Vim

I’ve always been ecstatic that Vim exists. I’m more ecstatic lately that I stumbled across Cream (for Vim).

The name was inspired by the convergence of several ideas. The initial thought came from my coffee drinking habits as I usually don’t prefer my coffee “black.” It reminded me of my opinion of Vim at the time–despite its inherent sophistication–I needed something to soften it.

Vim has a steep learning curve. It was not primarily designed to be easy to use, favoring performance and technical flexibility instead. Because it is so different, learning to use Vim takes time.

Cream shapes Vim into an interface you probably already know (sometimes called Common User Access [ext.link] ). Whether you are writing emails or developing large software applications, Cream saves you time and gets you up and running quickly.

If you, like me, are just looking for a vi clone for Windows that has syntax highlighting, I highly recommend Cream instead of plain Vim. Just download, install, configure your preferences (they auto-save), and get to it. You should note that Cream’s default behavior is not like traditional vi (insert/command modes), but it’s easily changed so don’t freak out.

Something I’m not pleased with, however, is Dreamhost storing historical support information for each user… including any passwords… in clear readable text. It’s quite possible a majority of Dreamhost customers are not even aware this is happening. More unfortunate, it’s very likely the customers don’t comprehend “what the big deal is.”

I’ve been doing UNIX, networking and security work professionally for 13 years now. There has never been a single instance where I needed to know a user’s password for anything. Under very rare circumstances I have had to change the user’s password to something I knew, perform some tests, then have the user set his or her password back however it was. None of it has ever required me knowing the actual password.

How did I find out about the Dreamhost practice? I didn’t have to go to any trouble at all. Any customer can access his or her “Panel” (a web-based Control Panel-like area), select “Support” from the menu on the left, then select “Support History” under that menu area. This will display a paginated record of all electronic communication the customer has had with Dreamhost support.

Here was my first eye-widening experience:

Here are the 2 responses I received from Dreamhost support staff when I pointed out the bogusness:

It was pretty clear to me from those responses that I wasn’t going to make any progress.

“But the Panel’s transactions are encrypted via SSL and getting at your information requires you to authenticate.”

Yes, and if I tell the Panel that I forgot my password, it is emailed to me over the Internet in clear text.

“Who cares? They’re support staff. They’re not going to do anything with your info.”

You sure about that? How about a hypothetical ex-Dreamhost staff member who collects data on the last day of his employment? This isn’t 1995 anymore. Situations like this occur on a daily basis. I’m sure you use a completely different password for every single need, too, right? Of course you do. I doubt you would be foolish enough to use your Dreamhost Panel password for your databases there, your GMail account, and other websites.

There is zero reason for anyone but me to know any password of mine. I don’t care who you are, what your role is, or how trivial you think the password-secured data is. This is Security Basics 201, and this is why every self-respecting and knowledgable IT person in your presence will turn his or her head while you type your password and get angry with you if you blurt out your password to him or her. We vehemently do NOT WANT to know your password. It is legally damning information.

Not only do you not need to know my password, you most definitely should not be storing them as clear text in a “Support History” database at your hosting company.

I love you Dreamhost, but it’s time to fix this.