Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

I was concerned when reading Kerberos: The Definitive Guide that Mac OS X clients bound to an Active Directory didn’t have an easy way to specify that their Kerberos tickets should work behind NAT. The option to obtain addressless tickets is defined in the krb5.conf file (or, for Mac OS X, the edu.mit.Kerberos.plist file) with:

noaddresses = true

… And it is not an option you can choose either in the Directory Utility GUI or the dsconfigad command line tool. This is important because addressless tickets don’t have IP addresses associated with them, and thus work in situations such as those where a client is behind NAT.

Before I submitted a feature request, though, I looked up the option in the krb5.conf man page on a Leopard system. I’m glad I did, because it says:

noaddresses

Setting this flag causes the initial Kerberos ticket to be addressless. The default for the flag is true.

Presumably, this documented default is applying on Leopard with Active Directory Kerberos. When I examined a TGT issued by a domain, I did not see any IP addresses associated with it, so the default does appear to be the case for me.

Under normal circumstances, the latest Radmind tools that communicate with the server report client status updates in the Radmind server’s system log. These standard messages can include ones like:

May 8 03:14:56 RadmindServerHost radmind[7890]: report radmind-client.example.com 192.168.7.42 - - ktcheck No updates needed
May 15 03:15:25 RadmindServerHost radmind[24531]: report radmind-client.example.com 192.168.7.42 - - ktcheck Updates retrieved
May 15 03:21:48 RadmindServerHost radmind[24534]: report radmind-client.example.com 192.168.7.42 - - lapply Changes applied successfully
May 15 03:31:07 RadmindServerHost radmind[24356]: report radmind-client.example.com 192.168.7.42 CertificateCN - lapply Error, changes made

The Radmind repo, or “report,” tool provides the ability to send arbitrary messages to the Radmind server process. But how are these messages formatted and sent?

$ repo -e "Debug" -h radmindserverhost.example.com -w2 "Test message"

… results in the system log message:

May 15 03:31:56 RadmindServerHost radmind[25236]: report radmind-client.example.com 192.168.7.42 CertificateCN - Debug Test message

Here, we can see that an entry created with repo looks like the standard Radmind log messages above. The client hostname and IP address are reported after the “report” text. The CertificateCN for the client — if the highest authorization level is specified (with the -w2 flag) — is also listed; if not, a dash takes its place. I haven’t seen a case where the second dash is substituted, however.

Finally, where the Radmind command/tool used would normally be, the “event” specified by repo will printed. After that, the message text appears.

The value proposition is that if you’re using Radmind, the repo command can help you send arbitrary messages to the server for logging. As bonus, if you've taken the time and effort to build the certificate infrastructure for Radmind, you can send these messages securely between the clients and the server cloaked in SSL.

If you’re using multiple servers, you may want to combine their logs in one location so that you can get all of the clients’ reports in one location. You may also want or need to retain these reports for more time. In either case, determine what policies you should apply to the syslog or Apple System Logger (ASL, for Mac OS X) configuration for your server systems.

Whether or not you use repo, it’s good to know that the tools do some logging. The logging can be followed to try to determine the status of your clients, or whether they are failing their updates.

Unfortunately, the most common client failures I have seen tend to involve the lapply tool, and the default level of detail I’ve seen reported back to the server does not provide an indication of what problem has been encountered. You see only that there was an error. Still, even though you may not get enough detail to remotely resolve the problem, it’s something for you to go by find problems in the first place.

I’ve found that trying to explain the Mac OS X keychain at all tends to make peoples’ eyes glaze over. The keychain is poorly-understood overall, perhaps because it tries to bridge the gap between security and convenience.

A few thoughts:

• A keychain has its own password which may or may not be set to the same as the password for the login account.
• The keychain password is completely independent of the login account’s password, even if it is the same text as the login account’s password. They can be changed independently. When they are the same, they are just two passwords which happen to be the same.
• User keychains are created within user home directories, and are protected by file system permissions while they are enforced.
• Keychain keys are further protected by 3DES encryption. Directory or metadata information is in cleartext.
• The Mac OS X Setup Assistant and Accounts System Preferences both create accounts whose login passwords and keychain passwords will match.
• If the password is shared between the login account and that account’s default keychain, the keychain will be unlocked during the login process. This is the default for accounts created by the Mac OS X Setup Assistant and Accounts System Preferences.
• If the default keychain’s password does not match the login account’s password, the keychain will not be unlocked automatically during the login process. The user may be prompted to unlock it, using the keychain password, if other applications require a key stored within.
• The only time that a password change for a login account changes that user’s default keychain password is when the login account is logged in and changes its own password through Accounts System Preferences.
• If the computer is bound to a directory service, a login account may be tied to that. However, the keychain is not. Changing the login account’s password through a directory service does not reset the keychain’s password. The keychain’s existing password will remain until or unless it is changed.
• A third-party software utility, Keychain Minder, can help to keep login and keychain passwords in sync, if desired. This may be especially helpful in a directory service environment, where you are more likely to change account passwords externally rather through Mac OS X’s built-in means. It also provides an opt-out capability for those who specifically want different login and keychain passwords.
• If the computer is bound to a directory service, and a directory service-based login account was compromised, there is a chance that the password for the default keychain in that account is also compromised. Changing the password for the login account in the directory service will protect the login account. However, that will not necessarily protect the keychain stored within the account’s home directory on disk. Whether or not the keychain password was the same as the former password for the login account — the keychain’s password should probably also be changed.
• The long-term use of the same password for a keychain can be a risk; as it gets stale, it lessens the protection on each key in the keychain.
• There is currently no policy enforcement mechanism, akin to pwpolicy, for keychain passwords.

Yes, I forgot to renew my domain. Yes, that became a real pain very quickly when I realized what the repercussions were.

For future generations, I suggest not having to deal with this when:

• you want to switch domain registrars
• you want to switch DNS hosting providers
• your goal is to save money
• you have never switched either registrars or DNS hosts for any domain before
• your domain’s WHOIS records are severely out-of-date (mostly because, through a comedy of errors, your host won’t let you update them)
• most of your administrative e-mail goes to a now-defunct mail address whose inbox you cannot access (I’m looking at you, .Mac, with your costs that went from $0 to $99/year in one year, and your vexing lack of forwarding)
• the rest of your administrative e-mail goes to an address in your expired domain (“because that’s the one e-mail address I’ll always have control over! Not like that .Mac account, no!”)
• you forgot that the reason why you didn’t switch domain and DNS providers earlier was because of the WHOIS hassle, and you just blithely plunged ahead with it
• you’ve waited until the day the current domain hosting provider has cut off your service (“hey, why can’t I connect to anything in my domain today? Er … ah … hm … oops. Maybe I should Twitter about this.”)
• you have to converse with the support organizations of at least two companies, and one of them is losing business
• you have better things to do with your life.

Lesson learned.

Anyway, it looks as if the long electronic nightmare of jaharmi.com being offline for Web and e-mail purposes has now ended. I can see this site. I can send and receive e-mail.

Good day.

Contrast this story at Daring Fireball, refering to this “Can You Count on Voting Machines?” story at the New York Times, with this article from our local paper regarding New York State’s tardiness in complying with the Help America Vote Act. Choice lines in the first two graphs:

“State officials took another step in New York's slowest-in-the-nation process of implementing an election-modernization law by filing a court-ordered timetable for having accessible voting equipment by September of this year and replacements for lever voting machines by fall 2009.

Board of Elections officials, who were excoriated by U.S. District Court Judge Gary Sharpe last month for running afoul of the Help America Vote Act, said the plan calls for the board to decide Jan. 23 which machines counties can choose for the disabled.” [My emphasis, especially on "excoriated."]

I'm all for accessible voting machines, if indeed our level-based ones and whatever alternatives are offered are not sufficient. But I'm a computer person, and as in the Daring Fireball commentary, I'm generally against implementing these new electronic voting systems just for the sake of having something new. There seem to be major problems with the systems that have been in the news, and I have a hard time wanting to lay our democracy on them at this time. Therefore, I have to wonder if New York State's delay isn't actually for the better.

(I wish I had a link handy at this very moment for the simple paper-based system I came across a few months ago, which sounded like a great solution that allowed anonymity, automated counting, and a verifiable vote.)

Hm. They actually tell you what’s new in Leopard — from a Mac OS X developer perspective, anyway — in the release notes section of the ADC Reference Library.

Who would have guessed? I think I missed this for Tiger. And, AFAIK, it wasn’t available at all for any previous version of Mac OS X. ’Twas a shame, quite a shame.

(I’ve always missed John Montbriand’s old overviews of the Mac OS classic releases; they were a treasure trove, relatively speaking, of information. Even for sys admins.)

I also found the man pages for process sandboxing in Leopard; it's found under "sandbox":

$ man sandbox

I found the man page for code signing in Leopard; it's found under "codesign":

$ man codesign

Update: It's worth noting that Apple has released the Code Signing Guide to document this feature further, from a developer perspective.

I never knew how to connect to an IMAP server when SSL/TLS were forced. With unencrypted connections, you can just Telnet in, but this exposes your login credentials and data, so many servers will not allow that. The secure equivalent to Telnet, I found, is OpenSSL’s s_client tool. The documentation clearly labels it as a debug tool.

You’d resort to either connection method for verification or troubleshooting purposes; I can’t imagine anyone wanting to do employ Telnet or s_client regularly — rather than use some mail client.

As an example, here’s how you could log into an Exchange account, select the “Inbox” folder, and log out:

$ openssl s_client -connect server:port -crlf
? LOGIN username password
? SELECT Inbox
? LOGOUT

The “openssl” line is typed at the shell prompt in your terminal (I used it from zsh in Terminal on Mac OS X Tiger, just for context). The “-connect” flag specifies the server and port (usually 993) to which you’re connecting. The “-crlf” flag is to send a CR/LF when you press Return; this is required for Telnet but is not done by default by s_client.

The rest of the commands are typed at blank lines provided by the s_client tool. To verify basic connectivity with Exchange IMAP, I found I needed to use a ? or a number preceding the commands. (Not being well versed in the internals of these protocols, I don’t know why, but I can follow directions.)

There is some basic info about s_client in the openssl man page, and there’s a man page devoted to s_client.

I also found an interesting source listing the capabilities of various IMAP servers.

Wow, I must be shopping too much — but not buying enough — at the iTunes Store. I’ve filled it up!

I had used the shopping cart feature since my first visit to the iTMS years ago. It has become my wish list. There is no other good wish list feature I’ve found that lets me save references to what I want to buy from any computer so that I can see them on any computer where I access my account.

I could, instead, build one or more playlists for this purpose — it is perhaps little-known that you can drag items from the iTMS to playlists in the iTunes software’s source list area. The playlists, however, are per-computer; they are not saved with my iTMS account the way the shopping cart is.

I could send each playlist I’ve saved in the iTunes software to the iTMS as an iMix. iMixes are intended for community sharing, however. Creating an iMix would mean that others could see what I’m intending to buy, so it’s not entirely satisfactory, either.

So, I stick with the shopping cart and I’ve simply got too much in mine for the iTMS to handle. I don’t know if it’s related to the number of objects or the total cost of what’s in my shopping cart or some other limitation, but it’s full. Now, I have to buy or remove items.