Latest posts by Timothy Warner (see all)
- Azure Server Management Tools – Manage on-prem servers through the web - Mon, May 2 2016
- LiteManager – Free secure remote access tool - Thu, Apr 28 2016
- Binary Fortress CheckCentral – Simplify and centralize your email notifications - Tue, Apr 26 2016
Here is the scenario: You manage a Windows Server 2008 Active Directory domain that includes both Windows 7- and Mac OS X-based client computers. Your Active Directory login scripts connect your Windows users to various corporate file shares and print queues. However, you need to make these resources available to your Mac OS X clients as well. How do you accomplish this goal?
Well, what are you waiting for? Let’s get to work at answering that question!
The Bitter Truth ^
As you know, a login script is a script file that contains a sequence of commands to automate our users’ environments. Naturally, the “logon” part of the login script means that the script file is applied during, well, user domain logon.
In Active Directory, we can create login scripts by using either a standard “DOS” shell scripts, or we can employ a Windows Script Host (WSH) compatible scripting language such as VBScript or Jscript. Other programming language options are available, but these are by far the most common.
We deploy login scripts by using either Group Policy or the user’s domain account properties sheet. The logon script files themselves need to be stored in the NETLOGON share of one of your domain controllers; Active Directory replication ensures that all domain controllers possess a copy of the login script file.
The preceding information is all well and good, but where does that help us with respect to applying logon scripts to Mac OS X clients? While Apple has given us rudimentary integration with Active Directory, a Mac system cannot process a DOS shell script or VBScript file—Macs simply do not have the appropriate command interpreters available to them out of the box. In point of fact, Group Policy is utterly irrelevant to the Mac OS X operating system.
Thus, unless we turn to third-party tools, we have to face the unavoidable conclusion that we must maintain a separate login scripts for Mac OX clients. This brings up the important questions, “Okay, but how do I accomplish this goal?”
To let the proverbial cat out of the bag, in this article series we shall investigate the following options:
- Defining a login item or login hook
- Leveraging Open Directory in Mac OS X Server
- Using a third-party utility
In future installments of this series, we will discuss the second and third bullet points. The focus of this article is to learn how we can create usable login scripts for our Macs with the least amount of effort, at least for the smallest of Mac/Windows environments.
Creating a login item ^
Login items in Mac OS X are directly analogous to Startup Items in Windows. In other words, these are applications that start up automatically after user login and are executed in the context of the current user.
To see a user’s login items, open the Accounts Preference pane, select the desired user account, and navigate to the Login Items tab.
The simplest way to add a Windows share to a Mac user’s login items list is simply to mount the share on the Mac in another 4sysops.com blog post) and drag the mounted volume to the user’s Login Items list.
Adding a Login Item
If you are looking for more robustness in how the SMB mount is performed, then allow me to suggest AppleScript. AppleScript is an interpreted scripting language that is almost as old as the Mac OS itself. Following is an extremely basic AppleScript that mounts the aforementioned SMB share:
mount volume “smb://user@server/share”
You can search online to find samples of more comprehensive AppleScript SMB scripts that include error checking, conditional logic, and so forth.
The key to using an AppleScript file as a login script is that you first need to save the script as an application (these have the .app extension by default). From the Apple Script Editor, click File > Save As and select Application from the File Format popup menu.
Saving an AppleScript as an application
You can then drag the AppleScript .app file to the user’s Login Items preference pane, as usual.
The finished configuration
Creating a login hook ^
Whereas a login item runs in the context of the currently logged on user, a login hook runs with root (superuser) privilege. Thus, login hooks tend to be much more powerful and have more capability than login items.
To define a login hook, you’ll first need to compose a UNIX shell script that performs the actions you desire. For instance, the following code creates a folder on the user’s Desktop and mounts a Server Message Block (SMB) Windows share named winshare from a Windows server named server01:
mount_smbfs //username:password@server01/winshare /Users/tim/Desktop/winshare
UNIX shell scripts typically have the .sh file extension. However, in this case we need to change the extension to .command as well as make the shell script executable. To perform this latter action, issue the following command from Terminal:
chmod +x filename.command
The final step is to create the login hook proper. From Terminal, issue the following statement:
sudo defaults write com.apple.loginwindow LoginHook /path/to/filename.command
where /path/to represents the path that leads to the .command shell script.
If for any reason you need to remove a previously created login hook, issue the following statement from Terminal:
sudo defaults delete com.apple.loginwindow LoginHook
While the techniques discussed in this blog post will work just fine for very small Mac/Windows environments with, say, 10 or fewer Macs, they are obviously unworkable for larger-scale implementations.
To this end, in the following installments of this series we will examine some methods for deploying login scripts to several Mac OS X clients in a more centralized manner. Advance warning: the next procedure we will examine involves Mac OS X Server with Open Directory, and will include almost no reference to Windows at all. The horrors, the horrors! Thanks for reading!