This document will explain how to configure a Mac running Tiger (Mac OS X 10.4.x) or Leopard (Mac OS X 10.5.x) or Snow Leopard (Mac OS X 10.6.x), such that all Penn State Access Account users will be able to log in to the Mac. The configuration will utilize Kerberos for authentication and LDAP for authorization.
Please Note: We have a public wiki documentation page that is updated more frequently than this page. This page might be archived soon!
First, verify which version of the Mac OS you are running, 10.4.x, 10.5.x, 10.6.x, or 10.7.x:
WARNING: If you intend to implement this method on Mac OS X Lion, be sure to upgrade to 10.7.2 or later. Mac OS X Lion 10.7.1 has a major security issue where if you configure a Mac with this method, passwords are NOT checked and anyone can login as another user.
- From the Apple Menu, select 'About This Mac'.
- Verify that the Version number is 10.4.x, 10.5.x, 10.6.x, or 10.7.x
|Tiger (10.4.x)||Leopard (10.5.x)||Snow Leopard (10.6.x)||Lion (10.7.x)|
Definitions For Terms Used in this Document
- A process that uses a piece of information provided by the user (typically a password) to verify the identity of that user.
- The determination of whether a user has permission to access a particular set of information.
- A network authentication protocol designed to provide strong authentication for client/server applications by using secret-key cryptography. The Penn State Kerberos server has entries for all PSU students, faculty and staff.
- Lightweight Directory Access Protocol (LDAP) is a method for providing directory information. While LDAP can be used to store many kinds of information, this document is concerned with storing information used during the authorization phase of Mac OS X login: the user's user identification number (uid), the user's group identification number (gid), and the user's home directory. Like Kerberos, the Penn State LDAP server has entries for all PSU students, faculty and staff.
- Login Process
- a multi-step process which includes both authentication and authorization as well as other system startup tasks.
Using Kerberos For Authentication And LDAP For Authorization
When using this configuration, you do not have to define any local users other than the administrator. Any user that has entries in the Kerberos and LDAP server will be able to log in to the Mac.
A current limitation of this method, as implemented in our public labs, is that all Kerberos/LDAP users must use the same folder as the home directory. Thus, you will have to write login and logout hook scripts to manage the users temporary home directory. We no longer provide such scripts, but rather point you to some resources that may contain helpful scripts. More on that at the end of this document.
Penn State/CLC OS X Kerberos Authentication and LDAP Authorization Installers
These OS X installer packages configure any OS X client to use Penn State's Kerberos and LDAP services for authentication and authorization, respectively:
Manual Configuration Details
- Configure Mac OS X for Kerberos authentication by following the steps in the Mac OS X Kerberos Authentication Setup document.
- Configure Mac OS X for LDAP authorization:
Testing the Kerberos and LDAP Configuration
Try logging in with your PSU Access Account userid and password. If you used your PSU Access ID as the Mac OS X administrative user, ask a colleague to login using their PSU Access userid and password. If you can logon using a Penn State Access UserID and password, you're done; everything must be correct.
If you can't login with a PSU Access Account userid and password, try the following debugging steps.
Test that the edu.mit.Kerberos file is correctly installed:
- Make sure your Mac has the correct date and time.
- Log in as the admin user (any user other than your Penn State Access ID user).
- Launch the Terminal application.
- Enter: kinit [accessID] where [accessID] is your PSU access ID.
- Enter your password when prompted to do so.
- Enter: klist (to verify that you got a Kerberos ticket).
Test that the /etc/authorization or /etc/pam.d/authorization file has been correctly edited:
- Log in as the admin user
- Create a local user with the same name and shortname as your PSU accessID. For example, I'd create a local user 'hkr'.
- Make sure the local user has a password that's different than your PSU Kerberos password.
- You should be able to log into the Mac with either your local password (try it) or your PSU Kerberos password (try that one too.)
Test that Directory Services is correctly configured:
- Log in as the admin user
- Launch the Terminal application.
- Enter: dscacheutil -q user -a name [accessID] where [accessID] is the PSU access ID of a user that is not a locally defined user. Try using hkr.
- If you don't get results from the PSU LDAP server, directory services is probably not configured correctly.
- To verify you have the syntax of the dscacheutil command correct, lookup the info for the local admin account:
- Enter: dscacheutil -q user -a name [AdminUser] where [AdminUser] is the admin user of the client Mac.
Note: If you made a mistake configuring Directory Services, you might have to go back to the Authentication Tab, remove the current LDAPv3 entry and add it back in. Apply the changes, and then restart the Mac to test again.
Mac OS X provides many other methods to authenticate and authorize users. For example, you could use Microsoft Active Directory server in place of Penn State's central LDAP server. This could allow you to restrict access to users who are only in your college's Active Directory.
Or, you might use an OS X server to authenticate and authorize users. You could provide home directories for users on an OS X server. And that OS X server might use Kerberos to authenticate users. All this is possible, but we haven't done it. Should you implement a different strategy for authenticating and authorizing users, please let us know. We could then work with you to add your documented methods to this document.
Where Can Users Save Files Permanently?
As previously stated, this Kerberos/LDAP solution utilizes temporary home directories. So, where can users save files permanently? These days, Penn State users can:
Your Home Directory Isn't Correct At Login
The first thing you will notice when logging in using the Kerberos/LDAP solution documented here is: the user logged in won't get a proper home directory. The solution we employ in the labs is to generate a fresh, clean, temporary home directory for each user as they login. We do this with login, logout, and system daemon scripts.
For various reasons, we no longer distribute our login and logout scripts. Not to worry; the University of Utah provides source code for their system called Xhooks (previously known as Entman or ULabMin). We highly recommend that you investigate their work at: University of Utah - Xhooks
Quoting a section of the University of Utah's web page describing Entman:
The scripts manage user home folders so that each user will have a "clean" home folder at login, configured exactly how the admin wants it. This ensures a secure and working home folder for each user. In addition to this, a lost and found is managed so that users can still access old files from previous sessions.
If you would like to allow every user to have their own unique home folder, follow the same steps to configure LDAP authorization but change the NFSHomeDirectoy attribute in step 21-B to "#/Users/$uid$". This will create a new home folder for every user that logs in. Beware, these home folders will not be removed at login/logout/reboot. You will have to script or manually remove the home directories.
Good luck. Should you have any questions please email: email@example.com.
Last Updated January 29, 2016