Connecting to a Directory System


In all but the smallest organizations, most of the Mac OS X Servers will be neither Open Directory masters nor Open Directory replicas. Instead, your file, Web, mail, VPN, iChat (Jabber), and other services will be configured to access one or more directory domainsOpen Directory, Active Directory, or otherwise.

This is the whole point of centralizing directory data. You maintain your user, group, and other administrative data centrally. Mac OS X (and hence Mac OS X Server) is extremely flexible in this regard. Realizing that an Open Directory master is not always the directory service of choice among its customers, Apple has engineered Mac OS X to be one of the most flexible cross-platform directory clients in existence today. Directory Access is the primary method for configuring that access.

When you choose Connected to a Directory Service in Server Admin, you will be directed to Directory Access to configure your connection to the other directory service (although you can also join an existing Kerberos realm as well) (Figure 3.26).

Figure 3.26. Choosing "Connected to a Directory System" from the Mac OS X Server, Server Admin, Open Directory role list.


Directory Access overview

The Directory Access application is used primarily to connect a Mac OS X or Mac OS X Server computer to another directory service or system.

Directory Access has three tabs: Services, Authentication, and Contacts. In practical terms, the Services tab lists all of the different types of directory services Mac OS X and Mac OS X Server can access, and allows each one to be configured (Figure 3.27). The Authentication tab lists the configured directory domains that will be searched for user, group, and other directory data (Figure 3.28). The Contacts tab allows configured directory domains to be used for contact information by the Mail and Address Book applications.

Figure 3.27. Clicking the Open Directory Access button in Server Admin opens the application Directory Access.


Figure 3.28. Viewing authentication path options from within Directory Access.


To understand how the Directory Access application works, you must be familiar with the concept behind what it does. Since Directory Access is based on a modular plug-in architecture, the application works differently depending on the plug-in used.

Let's say you have another Mac OS X Server already in your organization, and you want this Mac OS X Server to see all the users and groups you've created on your first server. Or, you have a Microsoft Active Directory server, and you want to see all the users in that directory service (provided you have the proper access). When you click the Services tab, you can choose from four different methods of connecting your Mac OS X and/or Mac OS X Server to another directory service:

  • Active Directory Use this plug-in to bind Mac OS X or Mac OS X Server to an Active Directory domain (as you'll see later in this chapter).

  • BSD Flat Files and NIS Use this plug-in to allow Mac OS X and/or Mac OS X Server to search locally for flat files (/private/etc/master.passwd) containing user and group information and/or allow it to use Sun's NIS, Network Information System (Figure 3.29).

    Figure 3.29. Binding a Mac OS X Server to an NIS.

  • LDAPv3 Use this option when you're connecting Mac OS X and/or Mac OS X Server to another Open Directory Server or any other LDAP-based directory service.

  • NetInfo You can use this plug-in when you're connecting a Mac OS X computer to an older parent NetInfo directory, such as Mac OS X Server 10.2 (Jaguar Server) (Figure 3.30).

    Figure 3.30. Options for binding a Mac OS X Server to an older NetInfo parent domain structure.

Checking authentication paths

Once you've chosen a method and the information is retrieved correctly, you can then have your Mac OS X and/or Mac OS X Server authenticate against that additional directory service.

Whenever a user logs in, Mac OS X and Mac OS X Server always check the local NetInfo directory first. If a user record isn't found in the local NetInfo directory, Mac OS X checks the authentication path for the username and password information, allowing the authenticated user to log in. That search list is handled on the Authentication tab of the Directory Access application (as shown in Figure 3.28).

This can be a multi-tiered situation. For example, suppose you want your Mac OS X computer users to log in to their machines, and their user names and passwords are stored on another directory server, not your Mac OS X Server. You don't have to create any entries in the Mac OS X local NetInfo directory. Simply have your Mac OS X Server piggyback on that other server for usernames and passwords, and then add computer management using your Mac OS X Server.

Tip

  • If you're working on an Xserve or managing your server remotely, you can connect to your server's Directory Access application through yours. To do so, launch your Directory Access application located in /Application/Utilities/, and choose Server > Connect. In the resulting dialog, type in the address or name of the server and the local administrator's name and password, and click Connect. You'll have to reauthenticate every five minutes while this application is open, so it's a good idea to get in, make your changes, save them, and get out.


Accessing an Open Directory domain

If you want, you can use the Server Admin application to begin the process of configuring your Mac OS X Server to access an existing Open Directory domain. This makes sense, since that's where other directory configuration (such as creating an Open Directory replica or master) takes place. Before proceeding with the following task, make sure your Mac OS X Server's Network preference pane has the correct information to see the domain name information for the other Mac OS X Server.

To access an existing Open Directory domain

1.

Launch Server Admin and navigate to the Settings section in the Open Directory module.

2.

Click the General tab, then choose "Connected to a Directory System" from the Role pop-up menu (Figure 3.31), and click Save.

Figure 3.31. Choosing the Connected to a Directory System option within Server Admin.


Now you can use the Directory Access application for the remainder of your server directory configuration process.

3.

Launch Directory Access by running it locally on the server itself or by connecting to your server remotely via Directory Access's Server menu and authenticate as required (Figure 3.32).

Figure 3.32. Remotely connecting to your Mac OS X Server's Directory Access application.


4.

Follow steps 311 in the "To bind Mac OS X to a Mac OS X Server Open Directory master" task earlier in this chapter.

5.

Open a Terminal window, type id paulv, and press Return.

Use the short name of a user in your shared (LDAP) domain instead of paulv. Your Mac OS X Server is now bound to the other Mac OS X Server's shared (LDAP) domain.

Joining a Kerberos realm

When a Mac OS X Server is connected to another directory system with a Kerberos infrastructure, you can choose to have your Mac OS X Server join a Kerberos realm. First you must have the KDC's administrator name and password (Figure 3.33). Once this has been done, services on your Mac OS X Server can accept tickets from users whose authentication information is maintained on the KDC.

Figure 3.33. Clicking the Join Kerberos button after binding to an Open Directory master.


Tip

  • If the Join Kerberos button doesn't work, ssh into your server and execute sso_util:

    sudo sso_util configure -r XSERVE.YOURREALM.COM -a youradminsn -p all.

    This will attempt to Kerberize your server.


Active Directory overview

Microsoft's Active Directory (AD) is one of the most commonly deployed directory services today. As such, integration with it is very important. Apple has engineered the Active Directory plug-in installed with Mac OS X to work well with AD.

Mac OS X is able to access Active Directory natively, without modifying the Active Directory's schema and without any extra software installed on the Mac. This enables AD accounts to make use of Mac OS X Server services like Mail, AFP, iChat, and Weblogs. Mac OS X Server can even store SMB home directories for Windows users.

In addition, Kerberos Single Sign-On is supported by an AD domain in much the same way that it is in Open Directory. Like most other directory services, this configuration takes place mostly in the Directory Access utility.

Before proceeding with the following task, make sure that your server is up to date and that forward and reverse DNS entries are properly configured. An Active Directory integrated DNS server should be listed as the first DNS server for the primary network interface in the Network pane of the system preferences application (Figure 3.34). Ideally, your server will also live in the same DNS domain as your Windows systems to facilitate Single Sign-On.

Figure 3.34. Ensuring that the Active Directory DNS is first in the list and that the search domain is set properly.


To bind to an Active Directory domain

1.

Launch Directory Access by running it locally on the server itself or connecting to your server remotely via Directory Access's Server menu and authenticate as required (Figure 3.35).

Figure 3.35. Showing the Active Directory plug-in within Directory Access.


2.

Select the Active Directory plug-in and click the Configure button.

or

Double-click the Active Directory plug-in.

3.

In the dialog that appears, specify the fully qualified domain name of your Active Directory domain (not the DNS name or IP address of your AD domain controller).

4.

Specify a computer ID (Figure 3.36).

For Mac OS X Server, this computer ID should correspond to the host portion of the server's fully qualified domain name.

Figure 3.36. Double-clicking on the Active Directory (AD) plug-in within the Directory Access application and entering AD-specific data.


5.

Click Bind. A dialog for supplying the administrative credentials appears (Figure 3.37).

Figure 3.37. After clicking the Bind button, you are asked to authenticate as an Active Directory user with write access to the OU specified in the path.


6.

In the Computer OU field, supply the credentials of a user with full control over the OU or CN and click Bind.

If binding is successful, the Active Directory Domain and Computer ID boxes will become unfocused, and the Bind button will become an Unbind button. The Active Directory bind will then be added to the authentication path (Figure 3.38).

Figure 3.38. A successful bind changes the windows and the default button to Unbind.


7.

Click the Authentication tab in Directory Access to ensure that Active Directory is now part of the authentication path and click Apply (Figure 3.39).

You may now access AD user accounts in much the same way you would Open Directory accounts: by assigning permissions, accessing Mac OS X Server Services, and provisioning access to Web resources.

Figure 3.39. Checking the authentication path to ensure Active Directory is indeed in the path.


Active Directory Single Sign-On

Once the Mac OS X Server is bound to Active Directory, users should now be able to access your server services that support Kerberos authentication. Note, however, that as of 10.4.3, this procedure will only work if your server exists in the same DNS namespace that Active Directory does. If any errors occur, consult /Library/Logs/slapconfig.log.


Tips

  • If binding is not successful, enable the DirectoryService daemon debugging by executing sudo killall -USR1 DirectoryService. View the resulting log in /Library/Logs/DirectoryService/DirectoryService.debug.log during a second bind attempt.

  • Common to both the LDAPv3 and Active Directory plug-ins in Mac OS X and Mac OS X Server 10.4 are the "Use for authentication" and "Use for contacts" check boxes, which prevent the extraneous trips to the Authentication and Contacts tabs required in v10.3 and earlier.


Using Active Directory with Open Directory

It's common to need more out of your directory services infrastructure than Active Directory can provide. Although basic Active Directory integration is feasible with no modification to the directory, Mac OS X supports a number of features that are not available on Active Directory. This is the nature of cross-platform integrationa certain level of commonality is feasible, but platform-specific features will generally mean requirements that a single directory cannot provide.

A frequent strategy for alleviating this shortcoming is deployment of peer directories. User, group, and other data lives in Active Directory. Mac-specific management data that Active Directory is generally incapable of providing lives in the Open Directory, and Mac clients are configured to access both. As of 10.4.3, Active Directory groups may be nested inside Open Directory groups using Workgroup Manager or the command-line dseditgroup.

By applying Mac OS X managed client settings to the Open Directory group that contains the AD group, users in the AD group are effectively managed, even though Active Directory cannot house Mac OS X managed client attributes. This is often known as the Golden Triangle, one corner being Active Directory, one corner being Mac OS X Server, and one corner being a Mac OS X computer.

To further this scenario, mobile home directories are often created to allow for home directory synching. The goal here is to:

  • Create an OD master.

  • Bind the OD master to an AD domain.

  • Configure Mac OS X computers to bind to both domains.

  • Synchronize local home directories for each user with directories on the OD master.

  • Allow user authentication to rely on the AD server.

Before any binding can occur, a machine that can store MCX attributes in records at the user, group, or computer level must be available on the network. Logically, the Mac OS X Server should be promoted to Open Directory master. Before proceeding with this task, first follow the "To create an Open Directory Master" and the "To bind to an Active Directory domain" tasks earlier in this chapter. Then in the Authentication tab of Directory Access on the Mac OS X Server, Active Directory must be listed before the server's own LDAPv3/127.0.0.1 connection.

To achieve the Golden Triangle scenario

1.

Create the Network mount point by following the "To create a home directory network mount" task in Chapter 5, "File Sharing."

2.

Launch Server Admin, start the Apple File Service, and use Kerberos as the authentication protocol.

For more on the Apple File Service, refer to Chapter 5.

3.

Launch the Workgroup Manager tool located in /Applications/Server, and authenticate as the administrator if necessary.

4.

Click the directory authentication icon and select the LDAP directory from the "Authenticate as" pop-up menu (Figure 3.40).

Figure 3.40. Choosing the shared (LDAP) domain in Workgroup Manager.


5.

Select the Accounts icon in the toolbar and then click the Groups icon.

6.

Choose the New Group icon and enter the group's long name and short name (Figure 3.41).

Figure 3.41. Creating a shared (LDAP) domain group.


7.

Open the users drawer by clicking the plus button next to the members window, and then select the group icon in the drawer.

The Users and Groups list will open on the side of Workgroup Manager (Figure 3.42).

There are two methods for creating groups from the Active Directory Users. One is to place the individual AD users into groups in the shared (LDAP) domain group. The other is to place AD groups into shared (LDAP) domain group. This second method, discussed here, refers to the new nested groups feature in Mac OS X Server 10.4 and avoids additional administration tasks.

Figure 3.42. Viewing the user and group drawer, initially showing the same LDAP domain.


8.

Choose the Active Directory Domain from the "Authenticate as" pop-up menu (and type in the AD group you wish to see if necessary by choosing Other from the list) (Figure 3.43).

The Active Directory group shows up in the authentication list (Figure 3.44).

Figure 3.43. Choosing the bound Active Directory domain from the list.


Figure 3.44. Typing in the partial name of the group lists only those groups in Active Directory with that name.


9.

Select the group that contains all the users who will be using Mac OS X and drag that group into the Members area; then click Save (Figure 3.45).

Your shared (LDAP) domain now has an Active Directory group within its own LDAP group.

Figure 3.45. Dragging the Active Directory group into the LDAP group to make a nested group.


10.

Select the Users tab in the Active Directory Domain, click the Home folder tab, and select a Home folder path for those users (Figure 3.46).

Figure 3.46. Selecting certain users to receive home directories that exist within the Active Directory domain.


11.

Click Create Home Folder at the bottom of the window before you click Save.

It is critical that home folders be created before the users ever log in.

12.

Click the Groups tab in Workgroup Manager and select the LDAPv3 group housing the AD nested group.

13.

Add mobile home folder options for the group.

Refer to the section "About the Mobile Accounts managed preference" in Chapter 13, "Client Management," for instructions.

14.

Follow steps 13 in the "To bind to an Active Directory domain" task earlier in this chapter to bind the Mac OS X computer(s).

Remember to use unique names for each computer.

15.

In the Active Directory plug-in window, click the Show Advanced Options disclosure triangle.

16.

Select the "Create mobile account at login" check box and deselect the "Require confirmation before creating a mobile account" check box (Figure 3.47).

Figure 3.47. Selecting the Mobile home folder options within Workgroup Manager.


17.

Continue with steps 47 in the "To bind to an Active Directory domain" task earlier in this chapter.

18.

On the Mac OS X computer(s), complete the "To bind Mac OS X to a Mac OS X Server Open Directory Master" task earlier in this chapter.

19.

Reboot the Mac OS X computer(s).

You should now be able to log in to a Mac OS X computer with a username and password that exists on the Active Directory server, have a local home folder created for you based on that account, and have that local home folder synchronized with an identical home folder on the Mac OS X Server.

Accessing eDirectory, SunOne iPlanet, or other LDAP directories

LDAP is a tremendously flexible protocol that shows an extremely wide scope of deployment. Because of this, it's difficult to generalize among different types of LDAP deployments. Even given a single directory service platform (eDirectory, for instance), a wide variety of deployed configurations exist. Because of this, mapping is incredibly important. Mapping attributes is one way to ensure a smoother transition from one directory service to the other.

Although this seems complicated, essentially all you're doing is connecting the dots:

1.

Determine the basic access configurationport number, search base, and whether or not SSL is in use. Also important in some cases are authentication semantics: authentication methods and whether or not authentication is required to access the directory. This has to come from the LDAP administrator, not you. You are attempting to make the Mac OS X Server conform to their directory service, not the other way around.

2.

Determine where user records are stored and whether or not sufficient data exists to support the Mac OS X user experience (at a minimum, a short name and numerical user ID should be available). If the attribute doesn't exist on the other directory service, you must either create that attribute or use an empty attribute and match the new name.

3.

Configure the LDAPv3 plug-in. Start with the RFC2307 mappings, and customize them according to the research you put into your LDAP directory (Figure 3.48).

Figure 3.48. Mapping options when faced with binding to another type of directory service.


Accessing or using BSD flat files

The final directory service technology this chapter will look at is Network Information Services (NIS). This technology is still used in certain places, and Mac OS X and Mac OS X Servers can authenticate against it using the BSD Flat File and NIS plug-in. It can also be used to authenticate against flat files that exist on the local disk.

To create a local user outside the NetInfo directory

1.

Choose the Accounts tab from within the System Preferences application to create a user with the Long Name Back Door and the Short Name backdoor (Figure 3.49).

This creates the home folder directory for the user backdoor (you can use any name that suits you).

Figure 3.49. Creating an account using the Accounts preference pane in System Preferences.


2.

Open the Terminal application, and type sudo mv /Users/backdoor/ /private/var/

3.

Press Return, and enter your administrator password when asked.

This moves the home folder of the user backdoor away from the normal location in the /Users folder and places it in the hidden /private/var directory.

4.

Open System Preferences, and delete the user backdoor by clicking the minus button below the list of users and clicking Delete Immediately (Figure 3.50).

This removes the user from the local NetInfo database; however, the home folder for that user has been saved and moved.

Figure 3.50. Deleting the just-created account.


5.

Open a new Finder window, choose Go > Go To Folder, and type /private/etc in the resulting dialog (Figure 3.51).

Figure 3.51. Viewing a hidden directory with Go To Folder under the Go menu.


6.

Open the file, master.passwd, in a text editor, such as vi or pico, by typing sudo vi master.passwd.

7.

View the last line of the file, and create a new last line of the file, mimicking everything you see except changing the following:

  • Short Name

  • User ID

  • Group ID

  • Home Folder path

  • Shell type

    For example, in the line backdoor:*:501:501::0:0:Back Door:/var/backdoor:/bin/bash, from left to right:

    • backdoor is the user's short name.

    • The asterisk is a placeholder for the password that will be changed later.

    • 501:501 is the user ID followed by the primary group ID.

    • Back Door is the user's long name.

    • /var/backdoor is the path to the home folder, which was moved into /var earlier.

    • /bin/bash is the user shell type.

8.

Save the file.

9.

Open the Terminal, and change the password for your new user by typing sudo passwd -i file backdoor and pressing Return.

Enter your password first if necessary, because you started the command with sudo. Then enter and reenter the new backdoor user's password to change it.

10.

While you're in the Terminal, type sudo chown -R backdoor:backdoor/var/backdoor, and press Return.

This command reassociates the backdoor user with the backdoor home folder.

11.

Open the /private/etc/group file (again using vi or pico) and add this backdoor user to the admin group, allowing them to have administrative privileges.

You've created a hidden user inside the local flat file with the same UID and group ID as the local administrator. You must now add the local flat files to the authentication search path.

Flat Files

Before there were directories to store user information, it was stored (on various operating systems) in plain-text files on the computer. Mac OS X and Mac OS X Server still contain these plain-text files and permit an administrator to add these files in the authentication search path via the Directory Access application. See the task "To create a local user outside the NetInfo directory" for more information.


To add flat-file searching to the authentication path

1.

Launch Directory Access and authenticate by clicking the lock in the lower-left corner of the dialog.

2.

Click the Services tab, and click the BSD Flat File and NIS plug-in check box if it isn't already checked (Figure 3.52).

Figure 3.52. Checking and double-clicking the BSD Flat File and NIS plug-in reveals...


3.

Click the Configure button to open the BSD authentication dialog.

4.

Click the "Use BSD local files (/etc) for authentication" check box and then click OK to close the dialog (Figure 3.53).

Figure 3.53. ...the check box necessary to allow it to access the master.passwd file.


5.

In Directory Services, click the Authentication tab and choose Custom path from the pull-down menu if not already selected (Figure 3.54).

Figure 3.54. Checking the Authentication tab and ensuring that Custom Path is selected.


6.

Click Add to open a list of Available Directory Domains.

7.

Select /BSD/local from the list and click Add (Figure 3.55).

Figure 3.55. Clicking the Add button reveals the newly setup BSD/Local authentication option to add to the path.


8.

Click Apply to commit the changes to your Open Directory architecture.

Your Mac OS X Server is now ready to have a hidden user authenticate from flat-file users.

9.

Log out, and then log in with your new hidden account.

Tip

  • By making the user ID the same as your initial user, you guarantee that the backdoor user will see user 501's files.





Mac OS X Server 10. 4 Tiger. Visual QuickPro Guide
Mac OS X Server 10.4 Tiger: Visual QuickPro Guide
ISBN: 0321362446
EAN: 2147483647
Year: 2006
Pages: 139
Authors: Schoun Regan

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net