- Introducing Directory Services Concepts
- What Is Open Directory?
- Overview of Open Directory Components
- Configuring Open Directory
- Managing Network User Accounts
- Connecting to the Shared LDAP Directory
- Configuring an Open Directory Replica
- Using Authentication Methods on Mac OS X Server
- Archiving and Restoring Open Directory Data
- Troubleshooting
- What You've Learned
- References
- Review Quiz
This chapter is from the book
This chapter is from the book
This chapter is from the book
Using Authentication Methods on Mac OS X Server
Open Directory offers a variety of options for authenticating users whose accounts are stored in directories on Mac OS X Server, including Kerberos and the many authentication methods that network services require. Open Directory can authenticate users by using:
- Single sign-on with the Kerberos KDC built in to Mac OS X Server
- A password stored securely in the Open Directory Password Server database
- A password stored as several hashes including LAN Manager, NTLMv1 and NTLMv2 (NT LAN Manager), and Microsoft Challenge Handshake Authentication Protocol (MS-CHAPv2), used for VPN—in a file that only the root user can access
- An older crypt password stored directly in the user’s account, for backward compatibility with legacy systems
- Local-only accounts, in which a shadow password is used, stored in a location accessible only by root
In addition, Open Directory lets you set up a password policy that affects all users (except administrators) as well as specific password policies for each user, such as automatic password expiration and minimum password length. (Password policies do not apply to crypt passwords.) Even though Mac OS X Server supports all of these different authentication methods, you should not use all methods. Crypt password support, for example, is provided for backward compatibility with older computers, but using crypt passwords is not as secure as using the Open Directory Password Server.
Configuring User Authentication
To authenticate a user, Open Directory first must determine which authentication option to use: Kerberos, Open Directory Password Server, shadow password, or crypt password. The user’s account contains information that specifies which authentication option to use. This information is called the authentication authority attribute. The attribute is not limited to specifying a single authentication option. For example, an authentication authority attribute could specify that a user can be authenticated by Kerberos and Open Directory Password Server.
You can change a user’s authentication authority attribute by changing the password type in the Advanced pane of Workgroup Manager. By default, the password type is Open Directory, which means that Mac OS X Server uses either Kerberos or Open Directory Password Server. Open Directory passwords are stored securely in a separate database, not in the user account.
)
A user’s account might not contain an authentication authority attribute. If a user’s account contains no authentication authority attribute, Mac OS X Server assumes a crypt password is stored in the user’s account. For example, user accounts created using Mac OS X v10.1 and earlier contain a crypt password but not an authentication authority attribute.
Disabling a User Account
If you want to disable a user from logging in, you can temporarily disable that user by using Workgroup Manager to remove access to his or her account. Doing so does not delete the user, nor does it change his or her UNIX user ID or any other information. Nor does it delete any of the user’s settings, preferences, or files created by that user. It simply prevents that user from authenticating and gaining access to the server via any method.
- Open Workgroup Manager and select the directory where the account resides that you want to disable. Generally, you will disable the OpenLDAP accounts, but you can also disable local accounts.
- Click the Accounts button, select the account, click the Basic tab, and deselect the “access account” checkbox.
- Save the changes.
)
Setting Account Password Policies
Once you create new users, it is useful to establish password policies for their network accounts. (There is more on setting these policies later in this lesson.) Should the users change their passwords next time they log in? Should there be a minimum password length? You can use Workgroup Manager to establish these and other policies for your users. These password policies can apply to just one user or to all users. Password policies applied with Workgroup Manager are called user account settings and are set for each user by clicking the Advanced button, then clicking the Options button.
)
Password policies applied with Server Admin are called global policies. In Mac OS X Server, user account settings may override global policies. Administrators are exempt from both types of policies. You will learn how to set global policies later in this lesson.
)
Set User Account Settings (Per-user password policies)
You will now set policies on a per-user basis as opposed to a global basis.
- Open Workgroup Manager and insure you are in the LDAP directory (LDAPv3/127.0.0.1). Select the user accounts you created earlier in this lesson and click the Advanced tab.
- Click the Options button.
- Select the following checkboxes:
- Disable login on specific date
- Disable login after user makes N failed attempts
- Allow the user to change the password
- Password must contain at least N characters
- Password must be changed at next login
“Allow the user to log in” will already be selected.
- In the “Password must contain at least N characters” field, enter 8.
The next time any one of the highlighted users logs in, they will need to change their passwords; the password will need to be at least eight characters long, and their account will be disabled on the date you chose.
- Click OK, then click Save.
)
)
Set Single User Account Settings
Now, perhaps you want to have only one of those users not be able to change their passwords, as in the case with a novice user.
- Select one of your users, click the Advanced tab if not already selected, and click the Options button.
- Edit the checkboxes to disallow all options under the criteria for password and disable the checkbox allowing the user to change his or her password.
- Click OK, then click Save.
Now, this user can’t change his or her password, and it is still set to expire on a given date.
)
Test User Account Policies
You will now move from your Mac OS X Server to your Mac OS X computer to test these policies.
- On the client computer at the login window, click Other, then attempt to log in as John Soward using the initial password
set for john.
Because you previously bound to the Open Directory master and there is no account record for John Soward on the Mac OS X client computer, the client searches the shared directory on the server to find a user account that matches.
- You are prompted to enter a new password, because you configured directory services to require the password to be changed at the next login.
- Enter johnj in the New Password and Verify Password fields, and then click Log In.
This login fails because earlier you set the password policy to require at least eight characters.
- Enter johnjohnjohn into the New Password and Verify Password fields, and then click Log In.
Because of the way Mac OS X Server functions, you still won’t be able to log in as john from your Mac OS X computer. This is because you haven’t set a home folder for the user john. However, the login fails and the login window shakes, even though the password has been changed. This can be confirmed by watching the Password Service Server log file in Server Admin. (Directory-related log files will be covered at the end of this lesson.)
)
)
Setting Global Password Policies
Open Directory enforces per-user and global password policies. For example, a user’s password policy can specify a password expiration interval. If the user is logging in and Open Directory discovers that the user’s password has expired, the user must replace the expired password. Open Directory can then authenticate the user.
Password policies can disable a user account on a certain date, after a number of days, after a period of inactivity, or after a number of failed login attempts. Password policies can also require passwords to be a minimum length, contain at least one letter, contain at least one numeral, be mixed case, contain a character that is neither a number or a letter, differ from the account name, differ from recent passwords, or be changed periodically.
Open Directory applies the same password policy rules to the Password Server and Kerberos. Password policies do not affect administrator accounts. Administrators are exempt from password policies because they can change the policies at will. In addition, enforcing password policies on administrators would subject them to denial-of-service attacks.
Kerberos and Open Directory Password Server maintain password policies separately. Mac OS X Server synchronizes the Kerberos password policy rules with Open Directory Password Server password policy rules.
After global password policies are put into effect, they are enforced for all users created or imported. For example, an existing user with the password wayne will not be required to change his or her password, even though you may have required more than eight characters and required the password to be different from the short name. This is because wayne’s account and password existed prior to the global policy being in place. In this case, it is best to require the user to change his or her password at the next login, thus forcing the user to conform his or her password to the recently set global password policies.
- Open Server Admin, if not already open, and select Open Directory from the list of services on the left.
- Click the Settings icon in the toolbar, then the Policy and Password tabs, in that order.
- Choose your own criteria to disable the login, choose what parameters the user’s password must meet, and click Save.
)
Using Single Sign-On and Kerberos
Frequently, a user who is logged in on one computer needs to use resources located on another computer on the network. Users typically browse the network in the Finder and click to connect to the other computer. It would be a nuisance for users to have to enter a password for each connection. If you’ve deployed Open Directory, you’ve saved them that trouble. Open Directory provides a feature known as single sign-on, which relies on Kerberos. Single sign-on essentially means that when users log in, they automatically have access to other services they may need that day, such as email, file servers, chat servers, VPN connectivity, and others without entering another password.
Defining Kerberos Terms
There are three main players in a complete Kerberos transaction:
- The user
- The service that the user is interested in accessing
- The KDC, which is responsible for mediating between the user and the service, creating and routing secure tickets, and generally supplying the authentication mechanism
Within Kerberos there are different realms, specific databases or authentication domains. Each realm contains the authentication information for users and services, called Kerberos principals. For example, if you have a user with a long name of John Significant and a short name of johnsig on a KDC with the realm of SERVER17.PRETENDCO.COM, the user principal would be johnsig@SERVER17.PRETENDCO.COM.
For a service to take advantage of Kerberos, it must be Kerberized (modified to work with Kerberos), which means that it can defer authentication of its users to a KDC. Not only can Mac OS X Server provide a KDC when configured to host a shared LDAP directory, but it can also provide several Kerberized services. An example of a service principal would be afpserver/server17.pretendco.com@SERVER17.PRETENDCO.COM.
Finally, Kerberos enables you to keep a list of users in a single database, called the KDC, which is configured on Mac OS X Server once an Open Directory master has been created. When a network user logs in on a Mac OS X v10.2 or later client computer, that computer negotiates with the KDC. If the user provides the correct user name and password, the KDC provides an initial ticket, called a Ticket Granting Ticket (TGT) that enables the user to subsequently ask for service tickets so they may connect to other servers and services on the network for the duration of the login session. During that time, the user can access any network service that has been Kerberized without seeing a password dialog.
Kerberos is one of the components of Open Directory. The reason a user’s password is stored in both the Password Server database and the Kerberos principal database is to allow users to authenticate to services that are not Kerberized. However, users must enter a password every time they access those services. Open Directory uses Password Server to provide support for those authentication protocols.
Because Kerberos is an open standard, Open Directory on Mac OS X Server can be easily integrated into an existing Kerberos network. You can set up your Mac OS X computers to use an existing KDC for authentication.
One security aspect to using Kerberos is that the tickets are time sensitive. Kerberos requires that the computers on your network be synchronized to within 5 minutes by default. Configure your Mac OS X computers and your servers to use the NTP, and synchronize to the same time server so this doesn’t become an issue in preventing you from getting Kerberos tickets.
Examining Kerberos Tickets
Even though you do not have a home folder at this point, you can examine your Kerberos Ticket Granting Ticket.
- Log in to your Mac OS X computer as cadmin.
- Navigate to /System/Library/CoreServices/ and open the Kerberos application.
- Click the New button in the toolbar to obtain a new Kerberos ticket.
Notice that because you are bound to the Mac OS X Server, you have SERVER17.PRETENDO.COM listed in your Realm field.
- Enter the short name and password that you entered earlier in Workgroup Manager and click OK.
- Because you set parameters on changing the password at next login, you are presented with a dialog asking you to change your password if you wish to obtain a ticket. Click Yes.
- Enter the old password you chose for the user, then enter and reenter a new password that conforms to the criteria you set
earlier on password restrictions and click OK.
You should now be able to view your Kerberos Ticket Granting Ticket. In later exercises, you will have a home folder and be able to view service tickets along with your TGT.
)
)
)
)
)
Notice that even though you logged in at the login window as cadmin, you were able to get a Kerberos TGT as another user. This is because you authenticated locally to your Mac OS X computer as cadmin, while your authentication mechanism for your other account originated on your Mac OS X Server, to which you have been bound during this lesson.