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

I came across an interesting “problem” with Active Directory binding on Mac OS X Leopard. The symptoms were:

• No Active Directory user accounts could log into the computer from the loginwindow.
• Some of the attempted logins involved cached mobile accounts from the Active Directory.
• The account login failures happened even though loginwindow’s “network accounts are available” indicator was green.
• The login problem persisted it the computer been unbound and rebound to the domain.
• The same Active Directory users could log in on other Macs.
• Local users could log in to the affected computer.
• Using “su” to switch users from a local user to an Active Directory user worked in Terminal.
• Lookups using “dscl” and other DirectoryService tools worked.

Since I’ve written (what seems like a) a book about Active Directory troubleshooting, I threw the book at this problem. It ended up taking quite some time to troubleshoot, and the answer ended up being very simple. However, it wasn’t on my normal list of culprits.

The biggest clue I found, besides the symptoms above, was that the DirectoryService debug logs yielded this during Active Directory logins from loginwindow:

It didn’t seem like a smoking gun, but I’d never come across this “false” response on a bound system before. So, what group was so important to the login process that the DirectoryService debug logs cared enough to note the failure? I was darned if I knew, and I had no other promising clues at that point.

So, I investigated that group further, and found it by its UUID using dsmemberutil:

Well, that helped a little, but the name would have helped a lot more. I had to find which group corresponded to the GID of 200. That GID was not at all familiar to me, but it was under 500, so there was a pretty good chance it came from Mac OS X.

This was my eureka! moment. I wasn’t entirely sure, but I was pretty confident that the “com.apple.access_loginwindow” group was the access control list group for the loginwindow process. Loginwindow controls all graphical logins to Mac OS X, and is the parent process of each GUI login session.

Looking up the group’s description confirmed that it was the ACL group. I did the lookup in Workgroup Manager, which was set to view the DSLocal directory service. While I was there, I also checked the membership: it listed only the computational group “localaccounts.” The “localaccounts” group is essentially a query that returns all accounts in the local directory service.

Well, that would certainly prevent Active Directory users from logging in with loginwindow. The ACL consulted the membership of the “com.apple.access_loginwindow” group to determine who was allowed to log in via the GUI. Because it contained only the “localaccounts” group, the ACL was preventing all non-local users from logging in.

Not knowing how this group was handled or even what had last edited it, I compared the affected system to a different AD-bound Leopard computer, which also had Workgroup Manager. (It’s handy to have the Mac OS X Server Admin Tools deployed out to your computers even if you don’t have a server to maintain.) The second computer didn’t have the group at all, which perplexed me a bit.

However, that made me reasonably sure I could simply delete that group. I backed it up from the filesystem at the command line, just to make sure, and then deleted it with Workgroup Manager on the affected computer.

After that, logins for all Active Directory accounts I tried proceeded normally at the loginwindow on that system.

With the problem solved, I sought more information about the workings of the “com.apple.access_loginwindow” group. I confirmed that it is created when the “Allow network users to login in at login window”
option is turned on in System Preferences > Accounts > Login Options. This should be turned on by default, and that initial state results in no “com.apple.access_loginwindow” group at all.

Since the option is on by default, the really simple solutions to this kind of problem are:

1. Don’t turn off the “Allow network users to login in at login window” option in System Preferences > Accounts > Login Options.

   

2. If “Allow network users to login in at login window” has been turned off, either:
   1. delete the group named above, or
   2. toggle the option back on.

Deleting the “com.apple.access_loginwindow” group removes it completely and reinstates login capability for both local and network user accounts.

Toggling the System Preferences option back on, adds the “netaccounts” group to the “com.apple.access_loginwindow” group, reenabling login for both local and network users. It does not, however, remove the group “com.apple.access_loginwindow,” which remains on the system afterwards.

Here's what that looks like in Workgroup Manager:

To prevent this on managed clients, I could see a system administrator proactively creating and managing the membership of the “com.apple.access_loginwindow” group. To ensure that managed clients bound to an Active Directory allow both local and network users to log in, make sure the group is populated with the appropriate nested groups: “localaccounts” and “netaccounts.”

I had an odd situation over the weekend that resulted in the inability to view the passwords associated with keys in my Mac OS X user keychain. Every time I clicked on the “Show password” checkbox in a key’s detail window, I’d get an “Access to this item is restricted” dialog.

Needless to say, this was disconcerting. I happened to have a lot of data in that keychain — this is what I get for keeping the same one around since Mac OS X 10.0 or 10.1. While I could revert to a backup, the newest backup wasn’t as recent as I would like. Plus, I just wanted to know why the problem had cropped up.

So, I asked about my problem on the Apple-CDSA mailing list. If anyone would be able to help with the obscure corners of keychains, I figured the people there would.

Very promptly, I got a reply from Ken McLeod, which led me to check the validity of the code signature on the Keychain Access utility.

Clearly, the signature and the application didn’t match. Something was amiss.

I reinstalled Mac OS X 10.6.2 on the system, using the latest combo update installer package, and cleared up the problem signature mismatch.

In retrospect, although I wouldn’t have thought of this being a problem, this breakage between the signature and the app — and its affect on my ability to view stored passwords — gives me confidence that thought has been put into the code signing mechanism in Mac OS X. You wouldn’t want a compromised app displaying your unencrypted keychain items, after all.

There is some important information in the Info.plist files contained in Mac OS X applications. But, some of that information isn’t really standardized — I’m looking at all of you, you crazy version number and vendor attributes (just the ones I'm interested in!). So, given that, how do you find them all to make comparisons between Apple and third-party apps?

Answer: You can use the “find” command to find all of the Info.plist files for applications in your /Applications directory.

$ find /Applications -name Info.plist -ipath /Applications/\*.app/Contents/Info.plist -depth 3 -print 2>/dev/null

Since that intentionally limits the depth traversal, you could modify it slightly to support finding Info.plists in your /Applications/Utilities directory, as well. However, I would say it’s less likely you’ll be dropping third-party applications in the Utilities directory, so you might not care.

When you have the print queue window open for a printer in Mac OS X Leopard, the Printer menu > Print Test Page command is active. That command sends the CUPS test page to the selected print queue.

The test page file itself is a PostScript document located at this path:

/usr/share/cups/data/testprint.ps

Since Leopard — like Mac OS X versions since Panther, has a built-in PostScript interpreter — you can open up this PostScript document and have it rendered as a PDF. By default, it will be sent to the Preview application.

It’s helpful to be able to view this document on-screen, so you can see what it is supposed to look like, in case your printer is not working as intended. You can compare the on-screen results with the printed output to verify how well your printer is working.

Mac OS X has a type of URL specifically for opening UNIX man pages. For me, using one of these URLs opens a new Terminal window to display the man page. Just put the name of the man page after the “x-man-page://” URL scheme to create one of these URLs.

For example, a link to the rsync man page would look like “x-man-page://rsync” when written out.

This is a handy way to refer to UNIX man pages with other Mac OS X users in e-mail correspondence, on mailing lists, or on the Web. Because of that, I wanted a quicker way to create these man page URLs. I wrote the Mac OS X Service named “Man Page URL for Command” to satisfy that desire. The “Man Page URL for Command” Service is provided “as-is” with no warranty.

The Service was wrapped up with ThisService by Peter Hosey, as with my earlier Mac OS X Service to shorten a URL with Bit.ly.

To install the Service:

1. Unzip the downloaded file.
2. Drag the unzipped Service to /Library/Services (for all users) or ~/Library/Services (for just the current user).

To use it:

1. Select a single word from some text you can highlight in an application. The word should ideally correspond to the name of a general UNIX command (“ls”), a Mac OS X-specific command (“dsmemberutil”), or another term the matches a man page (“sshd_config”). The Service is specifically coded to work only when you select a single word; if you select a text string with any white space in it, the Service will just return your original text. The Service also checks to ensure that the selected word corresponds to either a command in the $PATH or an existing man page, so it will not generate a “x-man-page://” for just any word.
2. Choose “Man Page URL for Command” from the Services submenu of the application menu. As long as you have selected only a single word that matches a command or existing man page, the selection will be replaced with the “x-man-page://” URL.

Thanks to Nigel for the inspiration.

Since the Bit.ly URL-shortening service is all the rage lately, and I hadn’t seen anyone create a Mac OS X Service for it yet, I decided to try my hand at it.

Here’s the result. The core is a relatively simple Python script and requires Mac OS X 10.5 (or Python 2.5 if you have an earlier version of Mac OS X). The Service was wrapped up with ThisService by Peter Hosey. It’s my first attempt at creating a Mac OS X Service — with or without ThisService — and I hope it works for you. However, it is provided “as-is” with no warranty.

That said, if you have comments or suggestions, please feel free to contact me.

Also, I’m not counting this as an endorsement of Bit.ly; I just looked at info on their site and thought I could probably script it and, as you can see, I did.

To install the Service:

1. Unzip the downloaded file.
2. Drag the unzipped Service to /Library/Services (for all users) or ~/Library/Services (for just the current user).

To use it:

1. Select the full text of an “http” or “https” URL that you’d like to shorten. (Don’t just select a site’s domain name. The Service is specifically coded to work on full URLs starting with “http” or “https.” So, “www.jaharmi.com” will not work but “http://www.jaharmi.com” will.)
2. Choose “Shorten URL with Bit.ly” from the Services submenu of the application menu. The selected URL will be replaced with the text of the shortened URL from Bit.ly. If it is not, the original URL will remain.

Of special note, however, is that if you shorten URLs with Bit.ly this way rather than through your browser, you probably won’t see them show up in your history (the most recent 15 URLs you’ve shortened). The script just shortens URLs for you and does so outside of your browser, so whatever cookies or other tracking Bit.ly is doing to generate your history, it doesn’t appear to carry over when using this simple little Service.

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.

There has long been confusion and misunderstanding about what, exactly, the Repair Permissions routine in Apple’s Disk Utility does. What started as the Repair Privileges Utility available separately for Mac OS X 10.1 has become the subject of some controversy in the intervening years.

“What permissions does it verify?” and “Where does it get the list of permissions it uses for comparison?” are two reasonable questions users and system administrators alike may ask in order to understand the software better.

The answers to these questions are important to prevent the abuse of this technique in the no man’s land of troubleshooting voodoo. Repair Permissions has been debated ad nauseum, but confusion blankets it like a thick fog. It’s 2008 and yet I still come across reasonable people who don’t know what the software is doing — sometimes even holding that it is doing something it isn’t.

Well, there is information available on this topic. First, let’s look at Apple Knowledgebase Article 25751: About Disk Utility’s Repair Disk Permissions feature. As of this writing, it states:

“When you use Disk Utility to verify or repair disk permissions, it reviews each of the .bom files in /Library/Receipts/ and compares its list to the actual permissions on each file listed. If the permissions differ, Disk Utility reports the difference (and corrects them if you use the Repair feature).”

That seems to imply that all of the Bills of Material (BOM) files for every package listed in /Library/Receipts are reviewed. But, the article further explains:

“No [Disk Utility does not check permissions on all files]. Files that aren’t installed as part of an Apple-originated installer package are not listed in a receipt and therefore are not checked. For example, if you install an application using a non-Apple installer application, or by copying it from a disk image, network volume, or other disk instead of installing it via Installer, a receipt file isn’t created. This is expected. Some applications are designed to be installed in one of those ways.”

The article implies that every package receipt is reviewed, but only the files and directories listed in an Apple-originated package are checked and repaired by Repair Permissions. This is somewhat confusing, since it doesn’t really explain how third-party software installed through an Apple installer package relates to this — particularly in the case where a file or directory is in both an Apple-originated package as well as a third-party one.

Macworld magazine’s Dan Frakes tackles the situation with the article Repairing permissions: What you need to know. The author tracks what BOMs Disk Utility is using while running Repair Permissions via fs_usage. He also runs strings on the tool that repairs permissions to find what, if any, BOMs are listed in the executable. Based on that evidence, he finds that a limited subset of BOMs are consulted by Repair Permissions — and all of them are Apple-originated; none are from a third party.

This dovetails nicely with the discussion of Repair Permissions in Michael Bartosh’s excellent Essential Mac OS X Panther Server Administration book from O’Reilly. While Mike is no longer around to explain how he obtained the list of BOMs — printed on page 163 — that are referenced by Disk Utility, it is likely he used one or both of the methods above. It is also likely he had access to information from Apple itself before he made the assertion. He always seemed to prize strong evidence and a deep understanding of the software, and so I trust what he wrote.

Mac OS X Leopard’s online help probably has the best clarification of the matter from an official source. It is succinct and much better than the Apple KB article when it spells out:

“Disk Utility repairs the permissions for files installed by the Mac OS X Installer, Software Update, or an Apple software installer. It doesn’t repair permissions for your documents, your home folder, and third-party applications.

You can verify or repair permissions only on a volume with Mac OS X installed.

It’s best to start up your computer using a disk with the latest version of Mac OS X, including software updates. Software updates may change file permissions to improve security.”

I think we can consider this matter settled; Disk Utility’s Repair Permissions routine is limited in scope. It only uses BOM files from Apple installer packages, and the only packages examined by the utility are those from Apple. Third-party software, even when installed by an Apple package, is not in the mix. The repair process only needs to be run as a troubleshooting technique when you think there is a problem related to the permissions-on-disk.

If you want to do your own sleuthing, the MacWorld article shows how to run strings against the DiskManagementTool executable to find which BOMs it lists. Modifying that a bit to get the information from any given disk you’ve mounted, and placing the output on the pasteboard (so you can paste it in the editor of your choice), you get the following (substituting the volume’s path for “/path/to/startupvolume,” or just take that text out to use your current startup disk):

$ strings /path/to/startupvolume/System/Library/PrivateFrameworks/DiskManagement.framework/Versions/A/Resources/DiskManagementTool | grep Receipts | pbcopy

Neither the DiskManagement framework nor the DiskManagementTool exists in Jaguar, however. I found that the on-disk structure of Disk Utility changed between Jaguar and Panther. After discovering that change, I thought I’d need to substitute “Disk Utility.app/Contents/Resources/Disk Utility Agent” for DiskManagementTool, but even that executable didn’t contain any references to “Receipts.” Instead, I settled upon the following for Jaguar:

$ strings /path/to/jaguarvolume/Applications/Utilities/Disk\ Utility.app/Contents/Resources/DiskFirstAid.bundle/Contents/MacOS/DiskFirstAid | grep Receipts

The result is much shorter: only 12 BOMs are referenced in Jaguar, in contrast to 47 in Leopard. For more, see Packages consulted by Repair Permissions in Jaguar, Panther, Tiger, and Leopard.

After my positive recent experiences with using Mercurial for some scripts, I’m thinking of writing a few posts about version control with Hg for systems administrators. I haven’t seen a lot of information about Mercurial written for that kind of audience. (I have so many small posting projects like this I want to do, sigh.)

I also wonder what it would be like to check a home directory into Hg, particularly on Mac OS X. I haven’t found any definitive answer as to whether it handles extended attributes (including ACLs and resource forks).

I’ve been a Life Balance user for years. I’m not a devoted user but I’ve found it a useful tool in those phases of my life where I felt the need to use an electronic to-do list. The concept behind the application has always just made sense to me, even if using it in practice is not as easy as falling off a log.

I recall that the first time I came across Life Balance, I devoured the Advice Book over lunch at Wendy’s and was excited by the possibilities the application offered. I am pretty sure this was back before there was even a Mac desktop application.

Now there’s finally a major update to the Mac OS X native desktop application. It’s Universal and is supposed to deliver on a lot of long-standing promises, like the addition of AppleScript support. Looking at version 4, it still seems to have its traditional clunky interface, and that’s been a big drawback to me. I simply find it ugly enough that I dread using the desktop application, and the full-featured Palm application feels cramped on my Treo. However, the new version does show some renewed public commitment to the product, which I would have otherwise said was in doubt.

Enter OmniFocus. I have been using it off and on for about a week or two, trying the “vaportrail” sneak peak versions. I’ve been suffering through the daily updates, which are thankfully handled with such great aplomb (probably by the Spark framework) that I hope more applications update themselves the same way in the future.

I love OmniFocus for its native Mac OS X feel. It’s fast, it shares a lot in common with OmniOutliner (which I already use frequently), and it looks like you’d expect a modern Mac OS X application to look. There’s also a good deal on the licensing right now, running until Macworld Expo.

But it still frustrates me. I’m not doing anything complex with OmniFocus, but I keep wishing it was Life Balance. Perhaps it’s because I’m not into the GTD meme; I’ve seen someone say that Life Balance is more Covey-based. But it feels as if Life Balance could do almost anything that OmniFocus could, and yet do more. So I feel that I should look at Life Balance again, especially with the discovery of the new version.

One big Life Balance advantage, from what I have seen so far, is that I can quickly get a flat, prioritized list of what I need to do in any given context. And, I can do that from a hierarchical outline of all of my projects and tasks. I’m having difficultly getting the same output from OmniFocus.

I wish Life Balance would become an application more like OmniFocus, or vice versa. I’d love it if the developers worked together. Sigh.