Understanding Mobile Accounts

Mobile accounts essentially are copies of network accounts that simultaneously exist in your directory domain (such as Open Directory, OpenLDAP, or Active Directory) and in the local domain (NetInfo) of a Mac OS X computer. Certain attributes are used to define a user account, and some of these attributes are copied to the local domain when a mobile account is created. This may seem confusing at first, raising such questions as "Where is the real password stored, on the server or the local computer?" or "How can a remote user be managed?"

Before implementing a mobile account, it is important to see the variety of ways in which such an account can be used, so that all the ramifications of a mobile account can be addressed, reducing the possibility that costly mistakes will be made.

Using Mobile Accounts

There are a couple of ways a mobile account can be used. First, a laptop, which contains only a local administrator account, can be imaged and given to a new user. When the laptop is connected to the local network before it is started up for the first time, a directory binding can be made to a directory service. The user types in a user name and password supplied by the directory administrator, and the following takes place:

• Certain user attributes are copied and/or created from the shared directory domain to the local NetInfo directory.

• A home directory is created and appears. This home directory is not a network home directory (it does not exist on a network server) but is a locally created home directory, based on the user template located in /System/Library/User Template/language.lproj, where language is the name of the localized language set for that particular laptop.

  The second way a mobile account can be used is similar to a laptop account except that, instead of being used on a laptop computer, it is used on a desktop computer. It may seem strange to create a mobile account on a computer that is constantly connected to the network containing the shared directory domain, but it has several advantages. For example, you could create a disk image that is deployed to hundreds or thousands of computers with nothing more than a single administrator account. When the image is deployed to a computer and initially booted, a user with a network account can log in and get a home folder created for her based on the local computer's user template. This keeps all user-created data local while the mobile account is a cached version of the network account.

  NetInfo caches the mobile user account and its various attributes.

  

  Should a problem with the local account occur, the local administrator can simply delete the locally cached NetInfo account for the mobile user and log out as the administrator. The user whose account has been deleted then logs in again. Once more, the account is cached locally. Since the administrator did not delete the user's home folder and the user's UNIX ID did not change, the user still has access to all her data. This is an extremely efficient way to manage thousands of users while allowing them to store their data locally on their computers.

  In either case, when the mobile user logs in and the computer is connected to the network on which the original account is stored, the account name, MCX settings, and password are updated on the mobile account.

Note

Mobile accounts are not good for users who may log in to three or four different computers during the day. Each time the user logs in, he or she will get a new local home folder, and the files created by the user will be on each computer, not housed in one location, such as a network home folder.

Implementing Mobile Accounts

Mobile accounts are created based on user, workgroup, or computer list accounts, depending on the types of accounts you wish to manage. For example, you may have a workgroup that contains all users in your company. You assign mobile accounts to the group, so any user who logs in as a member of the group will get a mobile account. Mobile accounts are handled equally regardless of whether you have 1 user or 10,000, 1 workgroup or 50, a computer list that contains all the Macs in your company, or just 5 laptops.

To implement a mobile account for a user:

1.	Launch Workgroup Manager.
2.	Connect to your directory server and authenticate.
3.	In the top right corner of the Workgroup Manager window, be sure the lock icon is unlocked to indicate that you are authenticated. If not, click it and authenticate.
4.	Select the user(s), workgroup, or computer list to which you wish to apply the settings.
5.	At the top of the window, click the Preferences button.
6.	Click the Mobility icon.
7.	Click the Always button in the Synchronization pane and select "Synchronize account for offline use."
8.	Click Apply Now.

Doing so will permit a local account to be created the next time that user logs in to a computer bound to that directory server.

Note

An option also exists to permit a dialog to appear requiring confirmation when creating a mobile account.

This can be done for many users, a group of users, or computer lists. Doing so will affect several accounts, not just one, as shown above.

But what happens when a computer with a mobile account is removed from the network? What if the password policy required the user to change his or her password every 30 days? How will the local account behave if the user attempts to log in on the 31st day?

When computers containing mobile accounts are disconnected from the network on which they were born, they act independently of the network because all their MCX settings have been cached locally. In the case of a password change, the user will still use his old password beyond 30 days until he can reconnect the laptop to the network. At the next login, he will be asked to change his password.

Mobile accounts can be combined with directory services to produce some versatile scenarios.

One option using mobile accounts is called the OD/AD (Open Directory/Active Directory) triangle. This consists of a Mac OS X Open Directory server as one corner of the triangle, an Active Directory server as another corner, and a Mac OS X computer as the third corner. The goal of an OD/AD triangle is to have the Mac OS X computer bind first to the Active Directory server and bind second to the Mac OS X Open Directory server. First the Mac OS X server binds to the Active Directory server, and then it binds to itself. In this fashion, users log in to a Mac OS X computer with a user name and password that exist on the Active Directory server and subsequently obtain a mobile account managed by a Mac OS X Open Directory server. Refer to Apple Training Series: Mac OS X System Administration Reference, Volume 1 for more information about connecting to an Active Directory server and the OD/AD triangle.