snowleopard.jpgMy last post looked at an issue where network users without a proper path assigned to their home directory in WorkGroup Manager would be unable to properly create a local home folder. This post looks at an issue with login failures that can arise with mobile network accounts under Snow Leopard Server. If you have mobile network accounts – AD or LDAP – that cannot login, jump to the bottom of this post for the fix.

After creating several network user accounts under Snow Leopard, I found that my test user account was unable to login. But instead of the standard shake of the login window that indicates a failed login attempt, the login window actually began to collapse as if the login process was starting – the login & password boxes disappeared briefly before reappearing suddenly & displaying the familiar shake to indicate that login had failed.

Interestingly, the user account could still be used to access system services without issue. Attempting to login to AFP shares or setup iCal for shared calendaring using the users login credentials worked fine.

Several reboots & rebinds later I dug through the system log to find the following error: error = Error Domain=NSOSStatusErrorDomain Code=-35 “Operation could not be completed. (OSStatus error -35.)” (no such volume).

Turns out the was unable to create the mobile account at login. The solution was to create it manually. On the client computer, login as an administrator & run the following two commands as root:

sudo /System/Library/CoreServices/ -n username

sudo createhomedir -c -u username

This forces the creation of both the mobile user account & their home directory. Log out & log in with your mobile user’s credentials – you should be able to login without issue. This should work for both Active Directory and Open Directory mobile user accounts.

Thanks to Rich Trouton of the macenterprise google group for posting the fix!

As of this writing, Snow Leopard Server is at version 10.6.1

snowleopard.jpgUPDATE: Due to some errors on my part, I have had to heavily edit this article. The information contained herein is now accurate. Sorry for the confusion!

I recently ran into a bit of an irritating issue while setting up directory services on a new server running Snow Leopard Server (10.6.1). It seems that as of 10.6, users without a value for their home directory (NFSHomeDirectory) are unable to create a home directory on managed clients. I had created a series of users and assigned them to groups. Every time I would log in to test, however, error messages would appear warning about problems creating the user’s home directory.

What is interesting, however, is that users can still access system services (AFP, iCal, etc) without issue. Attempting to login to AFP shares using the users login credentials works fine. Attempting to login to a managed client, however, generates a warning message about being unable to locate the users home directory. When logged in, the user cannot create new files or folders on the desktop – the whole system behaves as if the user has no permissions for the desktop.

A quick look at the logs on the server hinted that the issue was tied to home directories, with several warning messages about problems with home directories: CFPreferences: user home directory at /99 is unavailable. User domains will be volatile.

Sure enough, when I looked in WGM, I had forgotten to assign home directories to the accounts. I quickly corrected this (relatively large) oversight & BAM! clients were logging in without issue!

This is a fairly sharp departure from previous behavior. Prior to Snow Leopard, network users with no home directory assigned (NFSHomeDirectory=99) could still login; their home directories were simply created in a folder named “99” in the root of the boot volume (/99/user1). As of 10.6 this behavior seems to have changed. Why exactly, I’m not yet sure – although I imagine it must be tied to security.

My next post explores an issue where mobile account creation can sometime fail on login. Stay tuned!

As of this writing, Snow Leopard Server is at version 10.6.1.

iphone_homeApple’s recently released iPhone OS 3.1 has caused headaches & more than a little confusion for some users with Microsoft Exchange accounts. While the OS 3.1 update improves security policy adherence for iPhones when connecting to Exchange Servers, it also has the unfortunate side effect of breaking security compatibility with pre-3GS iPhones & all but the most recent iPod touches. The end result: many iPhone users who upgraded to OS 3.1 suddenly fond they could no longer sync with any Exchange Servers!

Fortunately, the synchronization issue is limited to Exchange 2007 Servers running SP1 & above, & there is a work-around to re-enable synchronization. Unfortunately, the work-around requires either convincing Exchange administrators to create a security policy exception or rolling back to OS3.0 on the iPhone.

In order to re-enable Exchange syncing with pre-3GS iPhones, Exchange administrators will need to create an EAS policy exception that will allow connections to mobile devices that do not support device encryption (either globally or on a per-user basis).

If the creation of policy exceptions is not an option (& that will likely be the case more often than not) there are 2 options: 1) upgrade to iPhone 3GS or one of the latest 32GB or 64GB iPod touch models, or 2) rollback to OS 3.0 (what will undoubtedly be the most popular solution).

The easiest way to rollback to OS 3.0 is obviously to restore the phone from a recent backup using iTunes (you did create a backup before you upgraded your phone, didn’t you???). Apple has a support article detailing how to backup, update, & restore iPhones & iPods. In case of emergency (ie: no recent backups!) you can go to this site to download firmware for iPhones & iPods. [NOTE: This site is NOT supported by Apple in ANY way!!!)

Finally, Apple has also updated it’s Enterprise Deployment Guide for iPhones. If you’re a sys-admin involved in the deployment & management of iPhones &/or iPods in an enterprise environment, this doc is a must-read.