OSX ML TT Integration

This document is intended for Apple internal and channel audiences, and is for training purposes only.

OS X Mountain LionTechnical Training: Integration

Apple Inc. © 2013 Apple Inc. All rights reserved.

Apple, the Apple logo, Finder, FireWire, Mac, Mac OS, and Safari, are trademarks of Apple Inc., registered in the U.S. and other countries. Apple Remote Desktop is a trademark of Apple Inc.

The absence of an Apple product or service name or logo from this page does not constitute a waiver of Apple’s trademark or other intellectual property rights concerning that name or logo.

Intel is a trademark of Intel Corp. in the U.S. and other countries.

IOS is a trademark or registered trademark of Cisco in the U.S. and other countries and is used under license.

UNIX is a registered trademark of The Open Group in the U.S. and other countries.

OS X version 10.8 is an Open Brand UNIX 03 Registered Product.

Other company and product names mentioned herein are trademarks of their respective companies. Mention of third-party products is for informational purposes only and constitutes neither an endorsement nor a recommendation. Apple assumes no responsibility with regard to the performance or use of these products. All understandings, agreements, or warranties, if any, take place directly between the vendors and the prospective users. Every effort has been made to ensure that the information in this document is accurate. Apple is not responsible for printing or clerical errors.

06-06-2013

OS X Mountain Lion Technical Training: Integration

© 2013 Apple Inc. Apple confidential—for internal and channel use only ii

Table of Contents...............................................................................Introduction 1

....................................................................................................About this series 1

.....................................................................1 Directory Services 2.......................................................................................Local directory services 2

.......................................................................Creating local administrative accounts 3......................................................................................................Open Directory 5

.........................................................................Setting up an Open Directory master 5..............................................................................................Binding to Open Directory 9

Binding to Open Directory using the Users & Groups pane in System ......................................................................................................................Preferences 11

..........................................................................................Custom binding operations 14.......................................................................Setting up an Open Directory replica 21

...................................................................................................Active Directory 24...........................................................................................Binding to Active Directory 25

...............................................Binding to Active Directory with Directory Utility 25...................................................Checking Active Directory binding information 29

.......................Commands for troubleshooting the Active Directory plug-in 33.................................................Mapping the UID and GID with Directory Utility 34

.....................................................................................Setting a user home directory 37..........................................................Active Directory packet encryption options 40

.................................................................................................SSL binding instructions 41.......................................................................................................................LDAP 42

.................................................................................................................Binding to LDAP 42....................................................................................................................Simple binding 43..................................................................................................................Trusted binding 46

..............................................................................................Mapping LDAP attributes 49.................................................................................................................Kerberos 54

...........................................................................2 Collaboration 56......................................................................Microsoft Exchange integration 56

............................................Using Mail, Calendar, and Contacts with Exchange 56.....................................................................Setting up out-of-office replies in Mail 61

..Troubleshooting Mail, Calendar, and Contacts with Microsoft Exchange 63..........................................................................................................................................DNS 63

................................................................Improper redirects and certificate errors 64....................................................................................................Limits on message size 65

................................................................Troubleshooting Microsoft Outlook 2011 66..............................................................Connecting to Microsoft SharePoint 66

.................................................................................Connecting to DFS shares 68...............................................................................................Instant messaging 69

...............................................................................................................................Messages 69.................................................................................................................iMessage on iOS 73

...............................................................................................................................FaceTime 73.............................................................Microsoft Office Communications Servers 74


© 2013 Apple Inc. Apple confidential—for internal and channel use only iii

.................................................................................Resources 77.................................................................................Command line help: man pages 77

..................................................................................................Advanced admin guide 77.......................................................................Third-party Active Directory plug-ins 77

..............................................................................................Third-party DFS solutions 77........................................................................Exchange troubleshooting resources 78

..........................................................................Microsoft Outlook 2011 Information 78.............................................................................Microsoft Communications Server 78

...............................................................................Microsoft SharePoint information 78

.................................................................................Appendix 80...............Creating a local administrative account using the command line 80

.....................................................................................................Hiding a local account 81........................................Making changes to the local administrative account 82

................................Nesting network admins in a local administrative group 82................Creating a local administrative account with a package or script 83

.........................................Binding to Open Directory using the command line 84...............................Binding to Open Directory using a postinstallation script 86

.........................................Binding to Active Directory from the command line 86..............................................................Binding to Active Directory using a script 88

........................................Binding to Active Directory using a postinstall script 88..............................Mapping UID, User GID, and Group GID using dsconfigad 89

.....................................................................Namespace support using dsconfigad 89....................................................Managing certificates from the command line 90.....................................................Active Directory computer password changes 91

..............................................................................................Viewing DFS with smbutil 91


© 2013 Apple Inc. Apple confidential—for internal and channel use only iv

IntroductionThis guide is designed to help organizations conduct proof-of-concept or broader end-user pilot testing with Mac computers in their environments. The guide is divided into two sections critical to successfully deploying Mac computers:

• Directory Services• Collaboration

Each section contains examples with step-by-step instructions for a variety of technologies using different strategies. For example, the Directory Services sections explain Open Directory, Active Directory, Lightweight Directory Access Protocol (LDAP), and other techniques. Choose the one that best meets your organization’s needs.

Before using this guide, you may want to speak with your Apple sales representative or Apple Authorized Reseller for assistance in determining the right modules to review for your environment.

About this seriesThis guide is one of a four-part series designed to help IT professionals who are evaluating and deploying OS X Mountain Lion on Mac computers in commercial and government organizations. The other guides in the series are:

• OS X Technical Training: Deployment• OS X Technical Training: Management • OS X Technical Training: Security

OS X Technical Training: Integration

© 2013 Apple Inc. Apple confidential—for internal and channel use only 1

1 Directory ServicesA directory service stores information about users, groups, and network resources for an organization. OS X maintains local directory services in the form of local accounts or by using network directory services, which obtain information from a centralized source. On a default installation of OS X, you can configure directory services to access directory service information with LDAP (Lightweight Directory Access Protocol) and Active Directory.

When an application, daemon, or utility needs information about a user, group, or computer, it does a directory service lookup. In OS X, directory information is always retrieved from the local directory service first. If the information isn’t located in local directory services, the query is sent to other directory services that have been configured. This search path is specified in the /System/Library/CoreServices/Directory Utility application. Administrators can specify the order to search the directory services for information such as users and groups.

Directory services in OS X are built using a modular framework. This framework allows directory services to be extended with third-party directory modules. These modules provide additional functions as well as other directory services support not included in the default operating system.

Local directory servicesLocal directory service information is stored in binary property list (.plist) files which are located in the /var/db/dslocal/nodes directory. Administrators acting as root can convert these files to xml .plists with plutil and then read, write, and change these files without needing an intermediary daemon. Administrators can also copy .plist files into the file system to create accounts. This flexibility is useful when you’re making mass changes to systems or troubleshooting a system in single-user mode. You can access and modify files directly, so scripting modifications to directory services is straightforward.

Accounts for users and groups are stored in flat files located in subdirectories in the /var/db/dslocal/nodes/Default directory. Users are stored in the /var/db/dslocal/nodes/Default/users directory and groups are stored in the /var/db/dslocal/nodes/Default/groups directory. Each user and group account has a corresponding property list (.plist) file containing an XML-like document describing the user or group. Accounts with an underscore (_) in front of them are reserved for system users and groups.

Inside each property list file are XML keys with an array of values that contain information about the user or group account. If you were comparing the local directory service files to an LDAP query, the file would be the object and the associated keys, and the values would be the attribute names and values for those objects. These keys in the local directory node closely resemble registry keys for local accounts, but they’re distributed across files rather than in a single location.

You can use different applications to edit local directory service information. For example you can use the Users & Groups pane of System Preferences to add, edit, or delete user accounts and groups. Directory Utility can also modify local accounts through the Directory Editor.

Although you can edit account property list files directly, it’s often safer to edit with directory services command line utilities. When you edit property list files directly, files aren’t checked for errors and changes aren’t immediately registered with the system. You can access these utilities from the Terminal application located in /Applications/Utilities.



The command line utilities and their roles include the following:

• odutil—Monitors directory services and manages directory services logging.

• dscl—Directory Service command line utility• dscacheutil—Looks up information, flushes caches, and gathers statistics on directory

services.• dseditgroup—Alters group membership information.

• dsenableroot—Enables or disables the root account.• dserr—Shows descriptions of directory services error codes.• dsexport—Exports directory services information.• dsimport—Imports directory services information.

• dsmemberutil—Checks group memberships and UUIDs and performs specific debugging operations.

• id—Validates user and group information.

Creating local administrative accountsFrequently, you need access to a local administrative account on each system that you want to centrally manage. Then you can use Apple Remote Desktop to remotely view machines and run local scripts on systems as postimaging tasks, and for management and troubleshooting purposes.

You can use the Users & Groups pane in System Preferences or the dscl utility from the command line to create local administrative accounts. To make it easier to manage tasks remotely, you can use the Active Directory plug-in to create local administrative accounts based on Active Directory group memberships.

Note: Refer to the Appendix for information about using the dscl utility.

Creating a local administrative account with System Preferences

The easiest way to create a new local administrative account in OS X is with the Users & Groups pane in System Preferences.

To create a new local administrative account:

1. Choose System Preferences from the Apple menu and click Users & Groups.

2. Click the lock icon in the lower-left of the pane and authenticate with an administrator’s password.



3. Click the Add (+) button in the bottom-left corner.

4. In the new account dialog, choose Administrator from the New Account menu.

5. Enter the new user’s full name and account name. (These names should be unique and different from each other.)

6. Enter the password in both the Password and Verify fields, then click the Create User button.

The new account appears in the Accounts list, under Other Users.

7. To make sure you created the account successfully with the appropriate administrative privileges, log out and log in again as the new user.



Open DirectoryOpen Directory is the directory services implementation built into OS X Server.

The Open Directory service in OS X Server includes a shared LDAPv3-based directory domain along with a number of schema extensions using registered Object Identifier (OID) space through Internet Assigned Numbers Authority (IANA). It also includes the Apple Password Server and Kerberos 5. Each component is integrated using the modular Directory Services subsystem.

The Kerberos service running in Open Directory allow users to authenticate to any service running on any server with their Open Directory credentials. The services must be kerberized and the server they’re running on must be bound to Open Directory.

Setting up an Open Directory masterIn Open Directory there can be an Open Directory master, Open Directory replicas, member servers, and clients. The Open Directory master runs LDAP and replicates the LDAP database to any replicas. The Open Directory master also runs the Password Server and maintains the Kerberos realm by acting as the Kerberos Key Distribution Center (KDC).

The following example explains how to set up an Open Directory master. Before you follow the steps, you need a fully functional server with OS X Server installed, with verified forward and reverse DNS records. This example uses Server.app.

To set up the Open Directory Master:

1. Before you set up the Open Directory master, make sure that the IP address matches the DNS records for the server. To do this, use the changeip command:

changeip -checkhostname

This command checks the current DNS information against the server’s IP address and makes sure that the DNS has been set up appropriately. If you receive any errors while running this command, repair the DNS and run the command again until it returns with success.

mainserver:~ serveradmin$ sudo changeip -checkhostname

Primary address = 10.10.100.9

Current HostName = mainserver.pretendco.com

DNS HostName = mainnserver.pretendco.com

The names match. There is nothing to change.

dirserv:success = “success”

IMPORTANT: The hostname and DNS could match while still being wrong. Before you continue setting up the Open Directory master, verify the system’s HostName is correct.

2. After OS X Server resolves the DNS correctly, open Server.app from the Applications folder.

3. Select your server on the “Choose a Mac” screen and authenticate to the server.

4. From Server, select the Open Directory service in the sidebar,.

5. Click the on/off switch to turn on the Open Directory service.



6. In the ”Configure Network Users and Groups” pane, select “Create a new Open Directory domain” and click Next.

7. In the Directory Administrator pane, enter the account information for the new Open Directory administrator account.

This account is different from a local administrative account because the Directory Administrator can only edit information within the Open Directory database, and can’t modify local accounts or modify service settings. The default name for the Open Directory administrator account is Directory Administrator and the default short name is diradmin. You can change these names. The default User ID is 1000, which can’t be changed in the Setup Assistant.

8. Enter the password in the Password and Verify fields.

9. Click Next.



10. In the Organization Information pane, enter your organization’s name and an administrator’s email address to be used for creating a certificate authority and some certificates.

11. Click Next.

12. In the Confirm Settings pane, make sure the settings are correct.

13. Click Set Up.



14. When the setup process is complete, click Logs in the sidebar and choose the Open Directory configuration log to review the setup logs.

15. The logs are spread throughout a number of files. Review the other Open Directory logs, looking for any major errors. Available logs are shown in the screenshot below.



16. Return to the Open Directory area in the sidebar and confirm the service is running and your master is in the list.

17. If you’re using a server for testing, consider removing the Open Directory information you created in this exercise (for example, if you want to start over using the command line or review logs more thoroughly to understand what happens if you change various options during the promotion). To delete an Open Directory master in Server app, select the master in the Open Directory service area and click the Delete (-) button. In Terminal, run the following command:

slapconfig -destroyldapserver

IMPORTANT: This command destroys all information in the Open Directory network domain.

Binding to Open DirectoryFor an OS X computer to access information in Open Directory, it must be bound to an Open Directory master or replica. Because Open Directory provides authentication and user management, you configure it in the Login Options section of the Users & Groups pane of System Preferences. Binding configures the LDAPv3 plug-in and allows the Directory Service daemon to access user, group, computer, and authentication information in Open Directory.

In this section, you’ll learn how to bind to an Open Directory server.

Before beginning this exercise, you’ll need the following:

• A Mac client computer with OS X• The local administrator user name and password for the Mac client computer• A working Open Directory master• A network connection between the Mac client and the Open Directory servers used in your

environment• A working DNS server with valid records for your Open Directory master



Because DNS records are crucial to an Open Directory environment, you must make sure that DNS is working properly.

To use Network Utility to validate DNS:

Open Network Utility and select the Ping tab. Enter the name of the Open Directory server in the text field and click the Ping button. The example below uses mainserver.pretendco.com as the name of the Open Directory master.

When the server responds to your request, your client is ready to be bound to the server.

If the server doesn’t respond, it may be because it’s configured with security options. To verify connectivity, use Network Utility to scan any ports in use on that server (for example, 389 for LDAP). To do this, open Network Utility and click the Port Scan tab at the top of the pane. Enter the IP address or host name of the server in the “Enter an internet or IP address to scan for open ports” field. Then select the “Only test ports between” checkbox, enter the range of ports you want to test in the fields, and click Scan.



Binding to Open Directory using the Users & Groups pane in System PreferencesThe easiest way to bind a Mac to an Open Directory master is by using the Network Account Server setup assistant in the Users & Groups pane of System Preferences. The setup assistant is a simple interface for binding and automatically detects whether you’re binding to Active Directory or Open Directory.

Note: To configure advanced options, open Directory Utility from the Network Accounts Setup pane or from /System/Library/CoreServices/Directory Utility.

To bind to Open Directory from the Users & Groups pane:

1. Choose System Preferences from the Apple menu.

2. Open the Users & Groups System Preferences pane.

3. Click the lock icon and authenticate to make changes.

4. Click Login Options.

5. Click the Join button next to Network Account Server.

A dialog appears allowing you to specify the directory service to connect to.

If you don’t need any customized options to communicate with your Open Directory servers, you can complete the binding process here. Advanced options are covered later in this guide.



6. Enter the name of the Open Directory master in the Server field.

7. Click OK.

OS X will first attempt to establish an SSL connection and verify that the certificate is trusted by evaluating the certificate trust chain. If the root certificate isn’t already trusted, you’ll be prompted to trust the SSL certificate.

8. Click Trust.



If the LDAP communication isn’t encrypted, you’re prompted to continue without a secure connection.

9. Click Continue.

10. If prompted, enter the Client Computer ID (the name of the computer record in Open Directory is provided), and enter a user name and password if you want to perform a trusted bind. Then click OK.

This step depends on server configuration, so it may not appear.



If the binding was successful, a green status indicator appears to the right of Network Account Server, followed by the the name of the directory server.

Custom binding operationsIf you need to perform a customized bind, you can use Directory Utility.

To perform a custom bind:

1. Open the Users & Groups System Preferences pane.

2. Click the lock icon and authenticate to make changes.


4. Click the Join button.



5. Click Open Directory Utility.

6. In the Directory Utility pane, click Services in the toolbar.

7. Click the lock and authenticate if necessary.

8. From the Services pane, select LDAPv3 and click the pencil, or double-click LDAPv3 to edit.



9. Click the disclosure triangle next to Show Options.

10. Click New.

11. Enter a host name for the server or IP address in the “Server Name or IP Address” field.

12. Click Continue.



13. Enter a Computer ID and optionally a network name and password to perform an authenticated bind.

14. Click Continue.

15. You can change the Configuration Name if you want.

16. Leave LDAP Mappings as is (From Server) for now. Changing mappings will be covered later.

17. Click OK.

18. To enable this new directory service entry to authenticate users, click Search Policy in the toolbar.

Note: Directories are searched for user authentication information in order, starting with the directory at the top of the list.



19. If the new connection doesn’t appear in the list, choose Custom path in the Search menu.

20. Click the Add (+) button to add the directory service.

21. Select the new LDAP service from the list provided.

22. Click Add.

.

23. Click Apply on the main Search Policy screen.

Note: If you need to customize further, go back to the Services button in the Directory Utility toolbar, double-click LDAP, then click the server you want to customize.



24. Click the Edit button.

25. Click the Connection tab to edit information you entered in the previous window, and customize time-out settings, custom TCP ports for LDAP, and so on.



26. Use the Search & Mappings pane to map specific records and attributes from the local system to those on the Open Directory server.

27. When you’re finished with your settings, click Save Template to make a copy, or click the “Write to Server” button to change your cn=config environment.

IMPORTANT: Be careful when using the “Write to Server” option because this option means all clients that are set up will get their settings from the server.

28. In the Security pane, you can add authenticated binding by selecting the checkbox labeled “Use authentication when connecting” and entering the distinguished name and password of the account you’ll use for connections,. You can also use the Security Policy section of this pane to enable policies that control how LDAP data is transmitted over your network.

Note: The server that the client computer is connecting to must allow these security policy settings.



Setting up an Open Directory replicaAfter you’ve configured the Open Directory master, it’s best to set up an Open Directory replica. If the Open Directory master fails, the lack of a functional directory service could prove devastating in many environments, because users may be unable to authenticate to local computers, or resources on servers could become unavailable. The replica synchronizes critical information from the Open Directory master, providing both redundancy and a way to balance load across servers.

To set up an Open Directory replica:

1. Open Server app from the Applications folder.

2. Select the Open Directory service.

3. Turn the service on.



4. In the “Configure Network Users and Groups” panel, select “Join an existing Open Directory domain as a replica.”

5. Click Next.

6. Enter the parent server hostname, and the Directory Admin name and password.

7. Click Next.



8. Confirm the settings and click Set Up.

The Open Directory replica is created and you return to the Open Directory service.



9. Click the disclosure triangle next to the master to see the Open Directory structure.

10. On the Open Directory master, use Server app to view the replica along with the last replication that was performed. Click Logs in the sidebar to look for errors that may have occurred during initial replication. (See “Setting Up an Open Directory Master” earlier in this document for more information about viewing log files.)

Active DirectoryActive Directory is Microsoft’s directory services solution. Active Directory provides information about users, groups, and computers (information stored in LDAP), password management and encryption (using Kerberos), and the ability to find objects on a network. Information in Active Directory is used to manage users, computers, groups, printers, and other resources. Within Active Directory, administrators can also use Group Policy Objects to assign policies to Windows computers.

Active Directory deployments vary, from smaller environments with a few hundred objects to larger environments with thousands (or millions) of users and systems distributed across a number of sites.

You can manually bind Mac computers to Active Directory through the Active Directory Service plug-in in Directory Utility. From the command line, use dsconfigad to bind and specify Active Directory–specific options.

Active Directory provides policies to Windows computers and the schema can be extended to include policies for other operating systems, including OS X. Some environments can’t extend their AD schemas so third-party solutions can provide policies to Mac computers without extending the schema.

In this section, you’ll learn some administrative tasks for managing OS X with Active Directory.



Binding to Active DirectoryYou can bind a Mac to Active Directory from the Users & Groups pane in System Preferences, through Directory Utility (located in /System/Library/CoreServices/Directory Utility), or with the command line utility dsconfigad. Although dsconfigad does contain some additional options, most configuration options are available through Directory Utility.

Active Directory validation

Before you start the binding process, confirm that the Mac can access the needed Active Directory resources for a successful bind. Because Active Directory clients use DNS service records to locate the Active Directory service, first make sure DNS is working properly.

1. Open Terminal and enter the following command to do a lookup on the service record to locate the global catalog:dig -t SRV _gc._tcp.pretendco.com; <<>> DiG 9.4.1-P1 <<>> -t SRV _gc._tcp.pretendco.com;; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34512;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:;_gc._tcp.pretendco.com. IN SRV

;; ANSWER SECTION:_gc._tcp.pretendco.com. 600 IN SRV 0 100 3268 dc.pretendco.com.

;; ADDITIONAL SECTION:dc.pretendco.com. 3600 IN A 192.168.55.47

;; Query time: 83 msec;; SERVER: 192.168.1.6#53(192.168.55.47);; WHEN: Thu Jul 31 14:09:32 2008;; MSG SIZE rcvd: 92

2. If the response doesn’t include an answer section with the name of a domain controller, check to make sure the OS X network settings are correct and that the DNS specified is one that will return service record information for your Active Directory forest.

3. To bind OS X to Active Directory, you need credentials of a local administrator on the Mac as well as of an Active Directory user who has the authority to join computers into the Organizational Unit (OU) that you’ll be leveraging in Active Directory.

After you have bound the Mac to Active Directory, you can set up the client to allow Active Directory administrators (or any Active Directory user you choose) to be local administrators on the local Mac client. During initial setup, you need the local administrative user name and password for the Mac. This user is the user set up in the Setup Assistant after installation.

Binding to Active Directory with Directory Utility

To bind to Active Directory with Directory Utility:


2. Open the Users & Groups pane.




4. Click the Join button next to Network Account Server.

5. Enter the domain name in the Server field.

The dialog expands for credentials and Computer ID (which autofills).

After you’ve joined the network account server, you can go back and look at the binding information and provide more details, if needed.



You can also see the Active Directory options in Directory Utility before binding if more information is needed to bind. To open Directory Utility, click the Edit button in the Users & Groups pane in System Preferences (or if the initial attempt at binding failed, click Join).

6. Click the Open Directory Utility button.

7. Double-click Active Directory (or click Active Directory and then click the pencil icon).



8. If you haven’t bound to the Active Directory domain yet:

a. Enter the Active Directory domain you want to join.

b. Change the computer ID if necessary.

c. Click OK.

d. Enter the Active Directory user with the delegated authority to bind a machine to the OU specified for Computer OU. Enter the Active Directory user’s password.

e. Click OK.



In the Users & Groups pane, a green light appears next to the domain if provided network accounts are accessible.

Checking Active Directory binding informationBefore you log out and log back in with an Active Directory user account, make sure that OS X is getting the necessary information from Active Directory.

In this section, you’ll learn how to make sure OS X can get information about an Active Directory user, browse information within Active Directory, and authenticate users.

For network accounts to work correctly, OS X needs to be able to look up information such as a user’s numerical ID (UID), primary group ID (GID), and group membership.

To verify that OS X can access information Active Director user information:

1. In Terminal enter the following:

id <Active Directory Username>

Sample:

Client-1:~ admin$ id jfoster

uid=818406992(jfoster) gid=1450179434(PRETENDCO\domain users)

groups=1450179434(PRETENDCO\domain users)

2. If the id command doesn’t return information about an Active Directory user, open Directory Utility and make sure OS X is bound to Active Directory and that Active Directory is listed under Search Path (the listing is created automatically when the client is bound). Also verify network connectivity between OS X and the domain controller, and check firewall settings on the network.



To browse the Active Directory network node:

1. Open Terminal and enter:

Client-1:~ admin$ dscl localhost

>

This places you in interactive mode.

2. To browse network nodes, type:

> ls

One of the listed nodes should be Active Directory (if not, Active Directory isn’t enabled in Directory Utility).

Active Directory

BSD

Local

Search

Contact

3. Type cd 'Active Directory' to get to the Active Directory node. Then type ls to list the contents of the node. An example is shown below.

> cd 'Active Directory'

/Active Directory > ls

All Domains

4. Type cd 'All Domains' to get to the All Domains node. Then type ls to show the contents of the node. An example is shown below.

/Active Directory > cd 'All Domains'

/Active Directory/All Domains > ls

CertificateAuthorities

Computers

FileMakerServers

Groups

Mounts

People

Printers

Users

5. Type cd Users to move into the Users container. The node should contain all of the users in the forest. If you have a lot of users, don’t use ls to list the contents of the User node. Instead type read <ad username> to view that user’s attributes. An example is shown below:

/Active Directory/All Domains > cd Users

/Active Directory/All Domains/Users > read jfoster

dsAttrTypeNative:accountExpires: 9223372036854775807



dsAttrTypeNative:ADDomain: pretendco.com

dsAttrTypeNative:badPasswordTime: 0

dsAttrTypeNative:badPwdCount: 0

dsAttrTypeNative:cn:

Tim Lee

dsAttrTypeNative:codePage: 0

dsAttrTypeNative:countryCode: 0

dsAttrTypeNative:displayName:

Tim Lee

dsAttrTypeNative:distinguishedName:

CN=Jimmy Foster,CN=Users,DC=pretendco,DC=com

more...

6. If you can’t read the attributes for a user, check access controls in Active Directory and make sure that you’ve bound to the correct OU.

7. Exit dscl.

/Active Directory/All Domains/Users > exit

Goodbye

To verify the user password:

Up to this point, the Mac can get information about users, but you must make sure that users can be authenticated.

1. Open Terminal and enter the following:

>su <ad username>

For example:

Client-1:~ Admin$ su jfoster

Password:

2. Enter the Active Directory user’s password (nothing will display) and press the Return key. You should now be in a Terminal session as that user. To check, use the whoami command.

>whoami

For example:

bash-3.2$ whoami

jfoster

3. To confirm that the Active Directory Kerberos is available type kinit and reenter the password.

bash-3.2$ kinit

Password for [email protected]:

4. If there are no errors, type klist to see your ticket. If there are errors, investigate and remedy them.



mailto:[email protected]

mailto:[email protected]

bash-3.2$ klist

Ticket cache: /tmp/krb5cc_ttypa

Default principal: [email protected]

Valid starting Expires Service principal

03/07/13 19:49:21 03/08/13 05:49:19 krbtgt/[email protected]

Note: If you see warnings about not having a home directory, disregard them at this point. The home directory is created on initial login.

To verify whether an Active Directory user account is active:

You can log out by choosing Log Out [user name] from the Apple menu, but it’s more convenient to use Fast User Switching to test the login window.

1. To enable Fast User Switching, choose System Preferences from the Apple menu, and click Users & Groups.

2. In the Users & Groups pane, make sure the lock in the lower-left corner is unlocked. If it’s locked, click the lock icon and authenticate to unlock it.

3. Click Login Options from the list on the left.

4. Make sure that the “Show fast user switching menu as” checkbox is selected.

A user name appears in the menu bar in the upper-right corner of your display.

5. Click the user name and choose Login Window.



After a cube transition, the login window appears. The current user session is still active. To return to it, select the original user in the Fast User Switching menu or at the login window.

6. Click Other, and enter the Active Directory user name and password. You can use the short name or the user principal name (UPN) name (for example JimmyFoster, jfoster, PRETENDCO\jfoster, or [email protected]).

You should now be logged in as the Active Directory user.

7. If the login window jiggles during authentication, make sure that you have completed the verify setting section above and validate the password. Or you can try a different Active Directory user account.

8. If you receive a warning that your home directory wasn’t found, open Directory Utility and check the settings for your Active Directory configuration. If you haven’t selected “Force local home directory on startup disk,” there’s an issue with mounting your network home directory. For this exercise, make sure the “Force local home directory on startup disk” option is selected.

Commands for troubleshooting the Active Directory plug-in

Active Directory DNS validation

If you’re having problems connecting to Active Directory resources, make sure the necessary connectivity is available to Active Directory. Use the steps above in “Binding to Active Directory” to verify that the appropriate service records are available in DNS (_gc, _ldap, _kerberos).

Checking accessibility

If you can look up the Flexible Single Master Operation (FSMO) roles for an Active Directory forest, you should be able to bind to the domain. If binding fails, a routing or switching issue might be keeping the client from communicating with the servers. Port 389 should be available to the client system for the domain controllers.

To check whether port 389 is accessible:

1. Open Terminal from /Applications/Utilities.

2. Type telnet <server.domain.tld> 389

If your connection is accepted, continue troubleshooting.

If the connection is refused, either the server isn’t listening for LDAP connections or the client is blocked from connection by something on the network. This could be a firewall or routing problem. Talk to the server and network administrators.

Authority

The Active Directory account you’re using to bind also needs the authorization to bind clients. In many cases, this means having access to a specific OU. Requirements may include having permission to remove objects from an OU—such as when binding and placing into a new OU—or full control over the domain. The access required for the account used to bind OS X should mirror that required to bind Windows clients.

Active Directory verification

When bound, make sure accounts are reachable using dscl and id. To use id, open Terminal and enter the following command to do a lookup using id. This returns the user and group information for the account. See the procedure above.



If you can’t look up a single account, the Active Directory connection isn’t working. Another tool that can isolate where in the directory services tree that a problem has occurred is dscl. Run the following command to see the plugins enabled on the system, and enter the dscl runtime environment. See the procedure above.

If you can’t cd into All Domains, you can’t communicate with a domain controller. If you can cd into All Domains, navigate into the Users node by using cd and perform another ls to show the contents of the node. The node should contain all users in the forest. If you have a large number of users, don’t enter ls to list the contents of the node, but rather use read to read the attributes of that user.

If you can’t read the attributes of a user, check access controls in Active Directory and make sure that you have bound to the correct OU.

User password verification

If the user’s password doesn’t work, make sure that you don’t have multiple users with the same short name in your Active Directory forest. If you do, you must enable namespace support with dsconfigad. To test this, enter a user name that has a unique short name forest-wide.

Mapping the UID and GID with Directory UtilityOS X identifies a user on the system with a Unique ID, or UID. The UID determines a user’s access to files and uniquely identifies a user on the system. Every group on the system is uniquely identified by a Group ID, or GID and every user is associated with a primary group. The user GID is the primary group ID for a user account. The user GID is set to the Domain Users group from Active Directory. However, on UNIX based systems, such as OS X, it’s common to set the staff group as the primary group for a user.

The UID for an Active Directory user account is automatically generated based on the Active Directory GUID for an Active Directory user because accounts created in Active Directory don’t contain the UID and GID values. If you’re in an environment where UIDs and GIDs have been populated in Active Directory, you can configure the Active Directory plug-in to use these values. If you’re unsure, consult with your Active Directory administrator about what values would be appropriate for this purpose. If these values aren’t prepopulated, and you want to do so, you may require additional scripts to populate fields within Active Directory for larger installations.

By default, UID, user GID, and group GID aren’t mapped from Active Directory fields to OS X when binding on the command line.

If you map UID, user GID, and group GID, make sure those attributes are indexed and available in the Global Catalog.

To map UID, GID, and group GID:






4. Click the Edit button to the right of Network Account Server.


6. Authenticate as a local administrator by clicking the lock icon in the lower-left corner, if it’s not already unlocked.



7. Select the Active Directory plug-in and click the pencil, or double-click Active Directory to edit.

8. Click the disclosure triangle to show advanced options.

9. Click the Mappings tab.

10. Enter the information needed to map to the Active Directory attributes. If you aren’t sure what values to enter, ask your Active Directory administrator.



11. Click OK to apply the changes.

Setting a user home directoryActive Directory attributes define where to store the the home directory for user accounts. The home directory can be in a custom location on the local computer that users log in to, on an accessible network share, or synchronized between a local directory and a network share (similar to using roaming profiles in an all-Windows environment).

In Active Directory, the location for profiles is defined in “Active Directory Users and Computers” for each user, or by a group policy object (GPO) attached to organizational units (OUs). Based on this information, you can synchronize the contents of the network location that contains the home directory with the local home folder.

To configure home directory management:






4. Click the Join button to the right of Network Account Server. This is an Edit button when the system is already bound to a directory service.



5. Click Open Directory Utility.

6. Authenticate as a local administrator by clicking the lock icon in the lower-left corner, if it isn’t already unlocked.

7. Select the Active Directory plug-in and click the pencil, or double-click Active Directory to edit.



8. Click the disclosure triangle to show advanced options, then click User Experience.

This pane includes the “Create mobile account at login” checkbox. Selecting this option creates an account on the local system so the user can log in even if the Mac can’t contact the Active Directory servers.

9. To turn on home-folder synchronization, select the checkbox labeled “Use UNC path from Active Directory to derive network home location.” If you select this checkbox, additional settings in the “Network protocol to be used” menu appear. The Active Directory plug-in converts the \\server\share\folder that the Active Directory profile provides to /server/share/folder and places either an “afp:” or an “smb:” in front of the request, resulting in afp://server/share/folder or smb://server/share/folder, respectively.

Active Directory packet encryption optionsYou can use the Active Directory plug-in to customize the encryption options used when communicating with Active Directory domain controllers in much the same way that you use policies to limit communications on the domain controllers. To customize encryption options, use the dsconfigad command line tool.

Packet signing is an option that many Active Directory environments require to prohibit man-in-the-middle attacks and ensure the authenticity of data while it’s being exchanged with Active Directory. Configuring packet signing options is a policy that’s configured on an Active Directory domain controller. In environments where packet signing is enabled, you can allow or even require packet signing from the client.

By default, packet signing is an allowed option in Windows Server 2003 and Windows Server 2008. Running various security tools automatically requires packet signing for Active Directory clients. In OS X, if you want to require packet signing for the client to communicate with the server, you can set the packet signing setting to require as well. If you require packet signing from either the domain controller or OS X, you should make sure before doing so that it’s an option on the other system.



To change packet signing options in OS X, use the -packetsign flag with dsconfigad. Available settings with the -packetsign flag are allow, disable, and require. To configure dsconfigad to require packet signing, use the following command: dsconfigad -packetsign require

If the change is successful, the following message appears:

Settings changed successfully

If necessary, set the signing back to default with the following command:

dsconfigad -packetsign allow

Packet encryption is also available in OS X. Packet encryption helps keep the contents as secure as they are authentic. To enable packet encryption, use the -packetencrypt flag along with the same settings available with the -packetsign flag. The same issues persist with verifying that the server supports packet encryption as with packet signing. To require -packetencrypt, use the following command:

dsconfigad -packetencrypt require

If you need to use TLS to encrypt packets, use the ssl option.

dsconfigad -packetencrypt ssl

The ssl option requires a trusted certificate chain from Active Directory. If the certificate chain doesn’t have a trusted root, you need to install and trust the root certificate in the root keychain.

If the change is successful, the following message appears:

Settings changed successfully

If necessary, set encryption back to default with the following command:

dsconfigad -packetencrypt allow

SSL binding instructionsEnvironments that require SSL to encrypt traffic between domain controllers and clients can use -packetencrypt with the ssl option. When using SSL, the Mac receives a certificate from the domain controller and evaluates the certificate trust chain to make sure the certificate is trusted. If the root certificate isn’t already trusted on the Mac, you must import and trust the root certificate, or turn off certificate verification.

To install SSL certificates:

1. Copy the SSL root certificate to the Mac.

2. Open Keychain Access from /Applications/Utilities.



3. Choose Import Items from the File menu.

4. Click System next to Destination Keychain.

5. Browse to the SSL root certificate and select the certificate you want to import.

A trust sheet appears.

6. Click the Always Trust button.

LDAPLightweight Directory Access Protocol (LDAP) is the protocol used in most modern directory services systems, including Novell’s eDirectory, Microsoft’s Active Directory, and Apple’s Open Directory.

LDAP defines how clients create, query, and update information in directory services and supplies that data, stored in a database, to clients and servers. OS X supports binding to any directory service that supports LDAP with the LDAPv3 Directory Service plug-in, which you can configure in the Users & Groups pane in System Preferences, with Directory Utility (located in /System/Library/CoreServices), or with the dsconfigldap command.

LDAP is flexible and supports different options for connecting, binding, and mapping to and from the fields of the LDAP database—called attributes. If you use Directory Utility or the dsconfigldap command, you can customize these options.

In LDAP, a schema is a set of rules about how data is stored in a directory service. Depending on the schema, you may have to provide custom mappings of directory service data in OS X with data in your directory service. Directory Utility provides templates (and the ability to create new templates for easy migration between hosts) to map to commonly used schemas. Directory Utility also supports mapping attributes via a special record stored in the directory service.

Binding to LDAPTo begin using an LDAP-based directory service, you must first bind OS X to your directory service with the LDAPv3 plug-in. The LDAPv3 plug-in supports simple binding, trusted binding, and Kerberos binding. Select a binding option based on your security requirements and settings configured on your LDAP servers.

• Simple binding configures OS X to look up directory service information with minimum configuration and security.



• Trusted binding requires the server to authenticate itself to prevent a man-in-the-middle type of attack.

• Kerberos binding provides digital signing of all packets, packet encryption, and man-in-the-middle attack prevention.

Note: Communication for all types of bindings can be encrypted with SSL.

Simple bindingBinding a Mac computer to an LDAP server with a simple bind tells the directory service’s framework of OS X to use an LDAP server as a potential location to find information, whether for simple directory lookups or for account information supplied at the login window. A simple bind tells directory services that a directory domain exists and, if requested specifically by configuring the Search Policy, that it should pull user and computer information from this directory service. You’ll then add the simple bind configuration to your Search Policy.

To enable a simple bind:

1. Open Directory Utility from /System/Library/CoreServices.

2. Select LDAPv3 and click the pencil, or double-click LDAPv3 to edit.

3. Click the New button.



4. Enter either the host name or IP address of your LDAP server in the Server Name or IP Address field.

5. Click Continue.

6. Enter a name for the configuration in the Configuration Name field.

7. In the LDAP Mappings menu, choose From Server, and enter the search base of your LDAP environment.

8. Click the OK button to apply this LDAP information.

Note: In most LDAP environments, users will want to authenticate against the directory services information being obtained. To add the new LDAP environment into your Search Policy, click Search Policy in the Directory Utility toolbar. By setting the authentication search policy, you set the order in which different directory domains are searched for account records.



9. Choose “Custom path” from the Search menu to tell the system to use the search path you’re about to add.

10. Click the Add (+) button to show the Available Directory Domains.

11. Click the LDAP environment you just added, then click Add. When you get back to the Directory Utility window, click Apply.

You can now use the dscl command to browse to the domain, authenticate as a user at the login window, and test other functions.



Trusted bindingUse the Users & Groups pane in System Preferences and/or Directory Utility (from /System/Library/CoreServices) to set up trusted binding between a Mac and an LDAP directory, if the directory supports trusted binding.

In a trusted bind scenario, the binding is mutually authenticated between the client and server with an authenticated computer record created in the directory upon binding (similar to the process in Active Directory).

A trusted bind setup is a static binding specific to the client hardware it was setup on. This means every computer must be bound after imaging.

To bind a Mac:

1. Choose System Preferences in the Apple menu.



4. Click the lock icon to authenticate to directory services.

5. Click the Join button (or the Edit button if the system has already been bound into a directory service).



6. Click the Add (+) button.

7. Enter the name of the server.



The dialog expands to include a Computer ID, a user name, and a password.

8. Confirm the Computer ID.

9. Enter a user name and password with privileges to the LDAP infrastructure.

10. Click OK. The computer will bind to Open Directory and a computer record will be created on the Open Directory master for this computer.

Note: The computer record might already exist in the directory if it’s a duplicate system or is being rebound after not unbinding properly. If an alert appears saying a computer record exists, click Overwrite to replace the existing computer record and then click OK.




12. Click Search Policy in the toolbar.

13. Make sure that the server is listed in the Authentication Search Policy. Add the server via the “Custom path” option if necessary.

14. Click Apply.

Mapping LDAP attributesIn OS X you can map attributes for accounts in an OpenLDAP environment to native Open Directory attributes. For example, you may have a different home directory attribute in an existing OpenLDAP environment. Rather than extending your OpenLDAP schema to include new attributes, simply map the attributes (useful in smaller environments) or push out mappings to clients from a centralized location (that is, using the cn=config container built into Open Directory).

Important: Before mapping Open Directory attributes to LDAP attributes, you must create a new LDAP configuration and specify the appropriate search base for the LDAP directory.



To map an LDAP attribute:

1. Open Directory Utility (from the Users & Groups System Preferences pane or from /System/Library/CoreServices).

2. Select LDAPv3 and click the pencil, or double-click LDAPv3 to edit.

3. Click the LDAP Mappings column.

4. If you don’t need to map individual attributes, choose one of the templates in the LDAP Mappings list.



5. To map individual attributes, select the entry for your LDAP server and click the Edit button.

6. Click the Search & Mappings button.

7. Choose Custom from the “Access this LDAPv3 server using” menu. A list of record types and attributes appears.

8. Click the Add button under the Record Types and Attributes list to show the record selection dialog.

9. Enter Users (for this example) for the record type you want to build a map for, select Users from the list, and then click OK.



10. Select Users in the Record Types and Attributes list and click Add again.

11. Select the Attribute Types radio button and search for NFS in the Attributes list.

12. Click OK again to select the NFSHomeDirectory attribute from the list.

The pane should look as shown below.



13. While NFSHomeDirectory is selected, click Add under the “Map to any items in list” option. Enter the name for the attribute (homeDirectory for this example) that you want to map to in your LDAP schema into the field that appears.

Now that you’ve entered a record, you can see that if you have 30 records and 100 systems, it’s labor intensive to map attributes one by one. There are two ways to streamline this process. The first is RFC 2307, which maps the OS X directory service to an RFC2307-based LDAP schema. For more information on RFC2307, see http://www.ietf.org/rfc/rfc2307.txt.

You can also store mappings on the LDAP server, and they’ll be discovered as long as the organizational unit is called ou=macosxodconfig. Mac OS X clients will perform an LDAP query on the LDAP server, searching for a record named “macosxodconifg” which contains the mappings. In Directory Utility, you can save the mappings to the server’s /Config container by clicking the “Write to Server” button. If you do this, enter the distinguished name and password for a user who has permission to write to the /Config object. Then enter the search base to discover the Config object.



http://www.ietf.org/rfc/rfc2307.txt

http://www.ietf.org/rfc/rfc2307.txt

14. Click the Save Template button to create a template.

15. Choose where to save the template, then click Save.

Note: In OS X, templates are, by default, stored in the Documents directory for the user account that created them, in the property list (.plist) format.

KerberosKerberos is a network authentication protocol that provides a client-server architecture where mutual authentication—both the user and the server—verify each other’s identity. This protects Kerberos against attacks such as eavesdropping, and the resulting potential of replay attacks.

Kerberos uses a Key Distribution Center (KDC) that consists of two parts: the Authentication Server (AS) and a Ticket Granting Server (TGS), which issues Ticket Granting Tickets (TGTs). Kerberos works with “tickets” that prove the identity of users. The KDC maintains a database of secret keys. All clients on the network share a secret key and use it to acquire a TGT. When the client has a TGT, it can present it to the KDC to get service tickets, which authenticate to kerberized services on the network. A kerberized service issues service ticket to clients. These service tickets are encrypted with the service’s private key. If a client presents an invalid or unverified service ticket to the service, the client’s service request is denied.

Note: For communication between two kerberized entities, the KDC generates session keys, which the KDC uses to secure communications.

In addition to authenticating a host’s identity in a Kerberos environment, safeguards are also put into place to protect the authenticity of each service running on a system in the form of a Service Principal. For a client to obtain tickets, the client requests a ticket using a TGT. You can view this information, in the form of Service Principals, with the klist command from the Mac to view cached service tickets.

A more detailed overview of Kerberos is beyond the scope of this document, but it’s important to know that when a user first authenticates to a KDC (whether it’s Active Directory, Open Directory, or an MIT/Heimdel-based KDC), the client receives a TGT. When the client authenticates to a



kerberized service, the client will have both a TGT and a service ticket for that service. This helps in troubleshooting authentication issues.

To use a graphical interface to access information regarding Kerberos tickets, open Keychain Access and choose Ticket Viewer from the Keychain Access menu. You can also manage Kerberos from the command line using kinit, kswitch, kdestroy, klist, kgetcred, and kpasswd.



2 CollaborationOne of the great challenges for IT departments is to optimize the sharing, storage, and retrieval of institutional knowledge. Apple has a number of innovative features available that promote collaboration. This chapter examines how you can use Apple tools and technologies to integrate with an organization’s existing collaboration solutions.

In many organizations, collaboration revolves around accessing groupware and corporate micro sites that are centered around Microsoft servers. In this section you’ll learn how to access Microsoft Exchange, connect to Microsoft SharePoint and DFS shares, and communicate with instant messaging servers.

Microsoft Exchange integrationStarting with Microsoft Exchange 2007, the Exchange Web Services (EWS) application programming interface (API) was designated Microsoft’s next-generation API for collaboration services. It’s designed to replace messaging application programming interface (MAPI) and collaboration data objects (CDO). The EWS protocol communicates over HTTP and includes a subset of features implementing Autodiscover.

EWS is a robust API targeting rich client platforms and shouldn’t to be confused with Exchange ActiveSync (EAS), which is only targeted at delivering service to mobile devices.

OS X ships with built-in support for Microsoft Exchange 2010. This native integration with Mail, Calendar, and Contacts in OS X relies on EWS, which requires a minimum version of Exchange 2007, Service Pack 1, Rollup 4.

Mail can also connect with previous versions of Exchange. However, without EWS, Mail uses the Exchange IMAP connector or POP to connect, providing access to email with no calendar and contact integration. This reduced access isn’t preferable for most organizations.

Using Mail, Calendar, and Contacts with ExchangeThere are three ways to configure Mail, Calendar, and Contacts to work with Exchange:

• Use the Mail, Contacts & Calendars pane in System Preferences.

• Set up Mail with Exchange Autodiscover, which also automatically configures Calendar and Contacts.

• Use a configuration profile that you can create with iPhone Configuration Utility or the Profile Manager in OS X Server.



To configure Mail using System Preferences:


2. Click the Mail, Contacts & Calendars icon in System Preferences.

3. Click Microsoft Exchange.

4. Enter the user’s name, email address, and password in the appropriate fields.



5. Click Continue.

Autodiscover should provide the user name, password, and server address for the account. If not, see “Troubleshooting Mail, Calendar, and Contacts with Microsoft Exchange” later in this chapter for more information.

6. Click Continue.

To configure Exchange accounts in Mail:

1. Open Mail.

2. If Mail hasn’t been configured with any accounts, the “Welcome to Mail” dialog will prompt you to add an account.



3. Enter the user’s full name, email address, and password.

4. Click Continue. If Autodiscover is properly configured, the account is automatically created. If not, enter the server information.

If an account has already been set up in Mail, you can add additional accounts in Mail preferences.

5. Choose Preferences from the Mail menu.

6. Click Accounts.

7. Click the Add (+) button to add a new account.



8. Enter the user’s full name, email address, and password in the Add Account pane.

9. Click Create.

Mail uses Autodiscover to attempt to look up the account information. If it finds the appropriate Autodiscover records, Mail will populate the input fields. After this is completed, check the content in each field, or provide the correct information.

10. If Autodiscover isn’t configured, choose Exchange from the Account Type menu and enter the server address, user name, and password.



11. If you want to automatically configure Contacts and Calendar at this point, select the Contacts and/or Calendars checkboxes.

12. Click Continue.

If Autodiscover doesn’t complete the setup process for you, see “Troubleshooting Mail, Calendar, and Contacts with Microsoft Exchange” later in this chapter for more information.

Setting up out-of-office replies in MailSetting an out-of-office response is useful when users may not be able to check email during vacation or illness. Users can configure out-of-office responses in the Exchange web client, or in Mail in OS X. In this example, you’ll review how to configure an out-of-office response.

To set up out-of-office replies for Exchange accounts in Mail:

1. Open Mail.

2. Right-click the name of the account (or Inbox if there is only one account) in the left sidebar.



3. Click Get Account Info.

4. Click the “Out of Office” tab.

5. Select the “Send Out of Office replies” checkbox.

6. Set the time during which replies will be sent (or leave the Until disabled option).

7. Enter reply messages in the Internal and External Reply fields (one for users inside your domain, the other for users outside your domain).

8. Close the Account Info pane.

The server will send out-of-office replies on behalf of the user.



Troubleshooting Mail, Calendar, and Contacts with Microsoft ExchangeMost administrators only need to troubleshoot Exchange connectivity during initial OS X integration. Many organizations rely on Autodiscover so clients can easily connect to their mailboxes from wherever they are. Autodiscover relies on Domain Name System (DNS) to point clients to the proper resources.

Mail queries DNS for the location of the Autodiscover service. The response from DNS should be the Client Access Server (CAS) for the Exchange organization. Once Mail knows where the CAS is, an Autodiscover request is sent over HTTP.

When the Internet Information Server (IIS) hosting Exchange Web Services (EWS) receives the HTTP request, it responds to the client with a request for authentication, and authentication is performed using the credentials provided to Mail. If everything is properly authenticated, the EWS service responds with the location LDAP, the Mail and Calendar servers, and the correct configuration information.

The Autodiscover protocol is designed to perform setup anytime a known mail server is unreachable. Administrators can move mailboxes based on server capacity without affecting user uptime or experience. Mail will rerun the Autodiscover process if and/or when mailboxes are moved on the Exchange server.

Troubleshooting the connection to Exchange can be broken down into several areas including DNS, Improper Redirects, Certificate Errors, and Limits on Message Sizing.

DNSMany organizations use Service Connection Points (SCP) to implement Autodiscover. This is usually sufficient for Windows clients that run Microsoft Outlook. However, if the proper forward and reverse DNS entries for Autodiscover haven’t been configured on the DNS servers, the Mac client can’t find the Exchange Web Services (EWS) service on the Client Access Server (CAS).

To verify SRV DNS record results:

1. On a Windows client computer, click Start, then click Run.

2. In the Open window, type CMD.

3. At the command prompt, type nslookup and press Enter.

4. At the nslookup prompt, type set type=all and press Enter.

5. Type _autodiscover._tcp.yourdomain.com

replacing yourdomain.com with the domain of the primary email address.

6. Press Enter.

The output should look similar to the example below.

*****************************************************************

> set type=all

> _autodiscover._tcp.yourdomain.com

Server: casserver.mail.yourdomain.com

Address: 192.168.1.100

Non-authoritative answer:



_autodiscover._tcp.yourdomain.com

primary name server = ns2.yourdomain.com

responsible mail addr = mailserver.yourdomain.com

serial = 1

refresh = 10000 (2 hours 46 mins 40 secs)

retry = 1800 (30 mins)

expire = 1814400 (21 days)

default TTL = 300 (5 mins)

_autodiscover._tcp.yourdomain.com nameserver = ns2.yourdomain.com

_autodiscover._tcp.yourdomain.com nameserver = ns1.yourdomain.com

Improper redirects and certificate errorsIf the client has problems connecting to the Exchange server, the SRV might be set properly, but the CAS might not be properly configured to accept Autodiscover requests. There could also be a HostName mismatch, or the server certificate might not have the proper Subject Alternative Name (SAN) and reverse IP lookup.

To trace these errors while setting up Mail, use the following command in Terminal.

/Applications/Mail.app/Contents/MacOS/Mail

-LogHTTPActivity YES -LogEWSAutodiscoveryActivity YES >&~/Desktop/

ConnectionLog.txt &

This opens the Mail app and logs all the traffic generated into a text file on the desktop. This log file is helpful when you need to troubleshoot connectivity issues.

To trace regular Mail activity beyond EWS Autodiscover, type:

/Applications/Mail.app/Contents/MacOS/Mail

-LogHTTPActivity YES >& Desktop/yourmaildebug.log &

To track EWS traffic in Calendar or Contacts instead of Mail, type:

/Applications/Calendar.app/Contents/MacOS/Calendar

-LogHTTPActivity YES >& Desktop/yourcalendardebug.log &

or type:

/Applications/Contacts.app/Contents/MacOS/Contacts -LogHTTPActivity YES

>& Desktop/yourcontactsdebug.log &



Limits on message sizeMicrosoft Exchange has a complex hierarchy of settings that governs the maximum message size for each mailbox. These settings can be configured with the Set-TransportConfig commandlet in the Exchange Management Shell. Because Mail relies on Exchange Web Services (EWS), you must modify the EWS website in the Internet Information Server (IIS) instance that is coupled with Exchange, in order to lift these restrictions.

To increase the message size for an entire organization, use the Set-TransportConfig commandlet. For an individual user, use the Set-Mailbox commandlet instead. For example, to increase MaxSendSize and MaxReceiveSize for a user called testuser, use the following command:

Set-Mailbox -Identity testuser -MaxSendSize 20MB -MaxReceiveSize 20MB

In addition to changing settings for maxMessageSize, maxReceiveSize, and maxSendSize for Connectors and Hub Transport servers, the 'maxRequestLength' in the EWS site's Web.config file must be changed to a similar scale value. The interaction of Mail with an Exchange server is routed through the EWS site and is therefore governed by this setting above all other message size limits as with other tools that interface with EWS.

For example, to limit message size to 20 MB, you must change the message size limits and the Web.config file via a process such as the following.

To locate the Web.config file:

• For Exchange 2007, the Web.config resides in \Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\ews.

• For Exchange 2010, the Web.config resides in Find, the Outlook Web App Web.config file on the Client Access server. The default location is \Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews.

1. Make a backup of the Web.config file.

2. Edit the Web.config file in Notepad.

3. Find the httpRuntime tag, under system.web.

4. Change the value for maxRequestLength to 20000, because the units are kilobytes.

5. Save the file.

6. Stop and restart the Default Web Site to make the setting take effect.

If you configure other Exchange settings for message size limits accordingly, changing this setting means OS X Mail users connected to an Exchange server can send messages as large as 20 MB.

The size of a message is roughly determined by the size of the message body plus the size of any attached files.

Note: Currently, Microsoft doesn’t document the configuration of maxRequestLength in the EWS Web.config file; they document it for OWA. The steps listed above are subject to change.

For more information, see this Microsoft article on managing message sizes for Exchange 2007 (http://technet.microsoft.com/en-us/library/bb124345(EXCHG.80).aspx) or this Microsoft article on managing message size for Exchange 2013 (http://technet.microsoft.com/en-us/library/bb124345.aspx).



http://technet.microsoft.com/en-us/library/bb124345(EXCHG.80).aspx


http://technet.microsoft.com/en-us/library/bb124345.aspx




Troubleshooting Microsoft Outlook 2011Microsoft Outlook 2011 relies on the Exchange Web Services (EWS) protocol for setup and connectivity so the DNS troubleshooting steps discussed earlier in the DNS section may be useful. That Outlook 2011 uses EWS is important to note because a Mail administrator may assume that because the product says Outlook, it can use Service Connection Point (SCP) objects to discover the email location. However, this isn’t the case for Outlook 2011.

Outlook 2011 uses a database to track each email message. The database is made up of pointers, not the actual messages. Each time a user receives email, a database write occurs, which can trigger activity from an antivirus application. If there’s a lot of activity, antivirus scanning can corrupt the database and crash email services. One potential solution is to make the following exceptions in the antivirus realtime scanner.

• /Library/Preferences/.GlobalPreferences.plist

• ~/Library

• /Users/.*/Documents/.*/Database/.*

• /.*\.log

Making these changes assumes that the incoming email message is scanned at the email gateway and at the server.

For more information about how to turn logging on or off in Outlook 2011, go to http://office.microsoft.com/en-us/mac-outlook-help/turn-on-logging-HA102928406.aspx?CTT=1.

Connecting to Microsoft SharePointMicrosoft has included the Microsoft Document Connection application in Office for Mac 2011and Office for Mac 2008. The Microsoft Document Connection is added to the Dock by default and is available in the /Applications/Microsoft Office 2011 and the /Applications/Microsoft Office 2008 folders, respectively.

Microsoft Document Connection works with SharePoint 2007 or later and provides the ability to check documents in and out. Microsoft Document Connection can authenticate using Kerberos as well as NTLM credentials, if the Mac isn’t yet bound to the Active Directory domain or if the SharePoint Server isn’t yet kerberized to the domain.

If you’re using SharePoint 2007 or later, you can use Safari to perform many of the common tasks performed with SharePoint, except for any feature that requires an ActiveX control. ActiveX isn’t supported by OS X.



http://office.microsoft.com/en-us/mac-outlook-help/turn-on-logging-HA102928406.aspx?CTT=1




To use Microsoft Document Connection with SharePoint:

1. Open Microsoft Document Connection from /Applications/Microsoft Office 2011.

2. Click Add Location.

3. Choose “Connect to a SharePoint Site.”

4. Enter the address, user name, and password for the site.



5. Select the “Save password in my Mac OS keychain” checkbox to save the credentials in the user keychain.

6. In Sharepoint in the sidebar, browse locate the file.

7. Click the file name.

8. Click the button in the top application toolbar that corresponds to the task you want to perform, for example, Add File.

Connecting to DFS sharesDistributed File Sharing (DFS) is one way to manage how storage is presented to the user. With DFS, Windows Server administrators can move shares between servers and can replicate shares across sites and servers without affecting the user experience.

SMB/CIFS is a file sharing protocol that users use to access DFS shares. In OS X, the Finder resolves DFS links and can access data on DFS shares the same as a regular file share.

To connect to a DFS share in OS X:

1. In the Finder, click the Go menu and choose Connect to Server (or use keyboard shortcut Command-K).

2. In the Server Address field, enter the path to the DFS share you want to access. (This may or may not be the root share.)

You can also, click the Browse button to see a list of servers on the network, and choose a DFS share from the list.



3. Click Connect.

4. If you’re using Kerberos, and you have permission to connect to the share, a window with the share’s contents appears. If you’re not using Kerberos, you’re prompted to enter a password. Enter the user name and password.

5. Click Connect.

Instant messagingOS X supports many standard instant messaging platforms. In the following section, you’ll learn about Messages, FaceTime, and integration with Microsoft Office Communications Server as potential instant messaging clients.

MessagesMessages is based on the XMPP instant messaging protocol commonly known as Jabber and works with AOL Instant Messenger (AIM), Yahoo, Google, standard Jabber servers, and iMessage. Jabber can be integrated with any instant messaging platform that also has an XMPP gateway.

To configure Messages as a Jabber client:

1. Open Messages (located in the Applications folder).

If this is the first time Messages has been opened, an account setup dialog opens.

2. Choose Preferences in the Messages menu.

3. Click Accounts, then the Add (+) button to add a new account.



The Account Setup pane appears.

4. Choose Jabber from the list of Account Types.

5. Enter an account name and password.

6. Click the disclosure triangle for Server Options.

7. Enter a server IP address and port number if necessary.



8. If applicable, select the “Use SSL” checkbox and the “Use Kerberos v5 for authentication” checkbox.

9. Click the Done button.

10. Close the Accounts pane.

11. Test the connection by adding users to the Messages Buddies list and chatting with them.

To configure Messages as an iMessage client:

1. Open Messages from the Applications folder.

If this is the first time Messages has been opened, an account setup dialog opens.

2. Choose Preferences in the Messages menu.

3. Select the iMessage entry on the left.

4. Enter your AppleID and password, and then click Sign In.



5. After signing in, you can do the following:

Enable sending and receiving iMessages: Select “Enable this account.”

View your Apple ID account information: Click Details.

Receive messages sent to email addresses and phone numbers: Click Add Email, and then enter email addresses. Select the email addresses and phone numbers you want to use to receive messages.

If you add a new email address for your Apple ID, a validation email is sent to that address. Follow the instructions in the email so that the address can be used with Messages.

If you have a phone number associated with your Apple ID, it’s automatically added to the list. When you set up your iPhone to use your Apple ID, your phone number is associated with your Apple ID.

Enable Read Receipts: Select “Send read receipts.”

If you enable read receipts, people who send you messages will see when you’ve read them.

Sign out: Click Sign Out.

Apple offers a number of tools for troubleshooting Messages connectivity. You can use Network Utility, an application in the /Applications/Utilities folder, to check whether private Jabber servers are accessible by name and IP address, and check that ports are accessible.

You can also enable debug logging for Messages. To debug communications with Messages, enter the following string in Terminal:

/Applications/Messages.app/Contents/MacOS/Messages -errorLogLevel 7

The most common causes for connection quality are bandwidth, gateway filters, and antivirus applications.



iMessage on iOSApple’s iOS 6 includes the Messages app that can connect to your iMessage account with your Apple ID. This connection lets you receive messages sent to your email addresses or phone numbers on your iOS devices and OS X computers.

FaceTimeYou can use FaceTime on your Mac to make and receive video calls with users on any device that supports FaceTime—another Mac computer, iPhone 4 or later, iPad 2 or later, or iPod touch (4th generation or later).

To participate in FaceTime video calls on your Mac, you need:

• An Internet connection. You can use Ethernet or Wi-Fi to connect to the Internet.• A Mac computer running Mac OS X 10.6.4 with all available security updates installed• A built-in FaceTime camera, an iSight camera (built-in or external), a USB video class (UVC)

camera, or a FireWire DV camcorder• A microphone. You can use the built-in microphone, an external microphone attached to your

computer’s audio input port, or a Bluetooth or USB microphone or headset.• Contacts. You can call FaceTime users whose contact information is kept in Contacts. To place a

video call to an iPhone, use a phone number. To call a Mac, iPod touch, or iPad, use an email address.

Signing in to FaceTime

Before making or receiving video calls, you need to sign in to FaceTime with your Apple ID.

If you already have an iTunes Store account or another Apple account, you can use the Apple ID associated with that account. If you don’t have an Apple ID, you can create one in FaceTime.

To sign in to FaceTime:

1. Open FaceTime and do one of the following

• Enter your Apple ID and password, and then click Sign In.

• If your Apple ID is displayed and you want to use it, click Sign In.

• If an Apple ID is displayed but you want to use a different one, enter an Apple ID and password, and then click Sign In.

2. Enter the email address others can use to call you in FaceTime, and then click Next to sign in.

If this is the first time you’ve used the email address in FaceTime, check for a new email message from Apple requesting that you verify that the address is a valid one to associate with your Apple ID. Simply click the Verify Now link in the message, and then enter your Apple ID and password.

After signing in, you can add an additional email address and adjust other FaceTime settings.

Managing FaceTime settings

After you sign in to FaceTime, you can use FaceTime preferences to review and change your FaceTime settings.

To open FaceTime preferences:

1. Choose FaceTime > Preferences.

2. When you’re finished with the preferences, click Done.



To manage Apple ID settings:

1. Click Account.

The Account field identifies the Apple ID you used to sign in to FaceTime.

2. Do one of the following:

• To change the country in which you’re using FaceTime, click Change Location to make sure that calls to iPhone users are made using the correct telephone number format.

• To display detailed information about the Apple ID you’re using, click View Account.

To manage email settings:

• To add an email address that others can use to call you, click Add Another Email, type an email address, and then press Return.

• To choose the email address you want others to see when you call them, click the email address displayed under Caller ID, and then select an email address.

• To remove an email address, click an Email setting, and then click Remove This Email.• If one of the following is displayed in front of an email address you entered, the address can’t

be used to initiate a video call:

• Verifying: The email address hasn’t been verified yet. Check for an email message from Apple requesting that you verify the address is a valid one to associate with your Apple ID.

• Error: The email address couldn’t be validated. This situation can occur if the email address is already associated with an Apple ID being used with FaceTime.

Microsoft Office Communications ServersThe Office 2011 suite includes the Communicator 2011 chat program, which has support for Office Communications Server 2007 R2 and later. The Communicator for Mac 2011 Deployment Guide is available at http://go.microsoft.com/fwlink/?LinkId=201946.

To set up Office Communicator:

1. Open Office Communicator from the Applications > Microsoft Office 2011 folder.

2. The first time the application opens, it will prompt you to make Communicator the default application for phone calls. If you want to make Communicatory your default telephony application, click Use Communicator.

3. From the Communicator menu, choose Preferences.



http://go.microsoft.com/fwlink/?LinkId=201946


4. Click Account. The account name is listed by email address. Click Change to assign a new account name.

5. Enter the email address, User ID, and password.

6. The default for My Network Settings in the Account pane is set to Automatic configuration. If you have a private Microsoft Lync server, select “Manually configure settings.”

7. Enter the server host name or IP address.



8. Choose whether to use TCP or TLS. (If you don’t know which option to use, contact the Communications Server administrator.)

9. Click OK when complete.

10. Click Sign-In.

You can now send files and email, video chat, or telephone contacts that are added to the Contact List.



ResourcesCommand line help: man pagesFor more information on local directory services command line tools, open Terminal in /Applications/Utilities, and enter “man <utility name>.”

Advanced admin guide

Additional information is also available in the OS X Server: Advanced Administration guide at

http://www.apple.com/advancedserveradmin/mac/10.8/

Third-party Active Directory plug-insAlthough the Active Directory plug-in in OS X works well for the majority of deployments, some may require a third-party solution. If you need to support native Active Directory Group Policy, or if you’re not able to extend your schema for policy objects specific to OS X, third-party plugins may help provide those features.

• Centrify—http://www.centrify.com/directcontrol/overview.asp

• ADmitMac—http://www.thursby.com/products/admitmac.html

• Dell—http://www.quest.com/authentication-services/

• PurpleRage—http://www.purplerage.com/likewise/enterprise.php

Third-party DFS solutions

Using a third-party client to provide DFS support on the Mac

The OS X implementation of DFS may not meet the needs of every network environment. Therefore, you can use third-party clients for DFS and test them to see if they support specific features not included in OS X. There are three third-party client-side solutions that you can use to work with DFS shares:

• Thursby’s DAVE—http://www.thursby.com

DAVE doesn’t depend on the built-in SMB client in the Finder; instead it uses its own browser (DAVE Browser), mounter (mount_cifs), and filesystem (cifs.fs) to browse DFS shares. DAVE is bundled with Thursby’s AdmitMac for Active Directory authentication, but DAVE doesn’t require AdmitMac and it can be used with the Active Directory plug-in built into OS X.

• Sharity—http://www.obdev.at/products/sharity/index.html

Sharity uses its own graphical user interface to configure mounts and a daemon that creates a virtual DFS mount that mounts volumes as you navigate the virtual DFS filesystem.

• GroupLogic—http://www.grouplogic.com

GroupLogic provides DFS link resolution via the ExtremeZ-IP AFP server solution. ExtremeZ-IP runs on a Windows server. The client application for DFS is a widget running on the Mac. The widget resolves DFS links by providing configuration to the mounting system on OS X or by using GroupLogic’s client application to query the ExtremeZ-IP web services running on a Windows server.





http://www.centrify.com/directcontrol/overview.asp

http://www.centrify.com/directcontrol/overview.asp

http://www.thursby.com/products/admitmac.html

http://www.thursby.com/products/admitmac.html

http://www.quest.com/authentication-services/

http://www.quest.com/authentication-services/

http://www.purplerage.com/likewise/enterprise.php

http://www.purplerage.com/likewise/enterprise.php

http://www.thursby.com

http://www.thursby.com

http://www.obdev.at/products/sharity/index.html

http://www.obdev.at/products/sharity/index.html

http://www.grouplogic.com

http://www.grouplogic.com

Exchange troubleshooting resourcesThe following links address common questions encountered when integrating Mail, Calendar, and Contacts into Exchange environments.

• Understanding Autodiscover in Exchange: http://technet.microsoft.com/en-us/library/bb124251.aspx

• Configuring DNS to support SRV records: http://support.microsoft.com/kb/940881

• Exchange 2007: Managing Message Size Limits: http://technet.microsoft.com/en-us/library/bb124345(EXCHG.80).aspx

• Exchange 2010: Understanding Message Size Limits

http://technet.microsoft.com/en-us/library/bb124345(v=exchg.141).aspx

• Exchange Server 2013: Understanding Message Size Limits: http://technet.microsoft.com/en-us/library/bb124345.aspx

• Exchange 2007: Managing Maximum Message Size in Outlook Web App:http://technet.microsoft.com/en-us/library/aa996835(EXCHG.80).aspx

• Exchange 2010: Configuring Maximum Message Size in Outlook Web App: http://technet.microsoft.com/en-us/library/aa996835.aspx

Microsoft Outlook 2011 InformationThere are a number of additional resources available for Outlook.

• Turn logging on or off in Outlook for Mac 2011: http://office.microsoft.com/en-us/mac-outlook-help/turn-on-logging-HA102928406.aspx?CTT=1

• Add support for Information Rights Management into Outlook 2011: http://go.microsoft.com/fwlink/?LinkId=201940

Microsoft Communications ServerFor more on Communicator, see the Microsoft Communicator for Mac page: http://www.microsoft.com/mac/enterprise/communicator

Integrating Messages with Microsoft Communications Server

To leverage the Messages application built into OS X while still integrating into an existing Office Communications Suite 2007 R2 or Lync Server environment, install an XMPP gateway service on the Communications server. To download the XMPP services package, see http://www.microsoft.com/downloads/en/details.aspx?FamilyID=aa560bfe-9960-473a-bfb8-53bff678cec4&displaylang=en.

For more information about adding an XMPP gateway, see Microsoft employee “OCS Guy’s” blog entry for adding XMPP services: http://www.ocsguy.com/2010/11/29/deploying-lync-for-xmpp/

Microsoft SharePoint informationMicrosoft has published a number of documents outlining how to use OS X to connect to SharePoint through Office for Mac. These include:

• Planning to Use Office for Mac 2011 with SharePoint:http://technet.microsoft.com/en-us/library/jj984193(v=office.14).aspx





http://support.microsoft.com/kb/940881

http://support.microsoft.com/kb/940881







http://technet.microsoft.com/en-us/library/aa996835(EXCHG.80).aspx

http://technet.microsoft.com/en-us/library/aa996835(EXCHG.80).aspx

http://technet.microsoft.com/en-us/library/aa996835.aspx

http://technet.microsoft.com/en-us/library/aa996835.aspx







http://www.microsoft.com/mac/enterprise/communicator

http://www.microsoft.com/mac/enterprise/communicator

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=aa560bfe-9960-473a-bfb8-53bff678cec4&displaylang=en




http://www.ocsguy.com/2010/11/29/deploying-lync-for-xmpp/

http://www.ocsguy.com/2010/11/29/deploying-lync-for-xmpp/

http://technet.microsoft.com/en-us/library/jj984193(v=office.14).aspx

http://technet.microsoft.com/en-us/library/jj984193(v=office.14).aspx

• SharePoint: Working with Documents Stored in a SharePoint Site Using Document Connection: http://social.technet.microsoft.com/wiki/contents/articles/10527.sharepoint-working-with-documents-stored-in-a-sharepoint-site-using-document-connection.aspx



http://social.technet.microsoft.com/wiki/contents/articles/10527.sharepoint-working-with-documents-stored-in-a-sharepoint-site-using-document-connection.aspx




AppendixThis appendix contains advanced techniques for managing accounts, directory binds, and certificates using the command line interface (CLI).

Creating a local administrative account using the command lineA variety of user administrative tasks can’t be completed using the OS X graphical user interface (GUI), including customizing the location for a user’s home directory, adding additional short names, changing short names, and automating the process of account creation. Instead, the dscl command line utility can be leveraged to create a local administrator account through the command line.

To create a local admin account via the command line:

In the following steps, replace pretendcoadmin with an actual short name for a new account and replace Pretendco Administrator with the full name of the new administrative account.

1. Add the user name to the local directory services information store database using the following command:

sudo dscl /Local/Default create /Users/pretendcoadmin

2. Set the login shell to be used. Bash is the standard used in most OS X environments:

sudo dscl /Local/Default create /Users/pretendcoadmin UserShell /bin/

bash

3. Set the full (or long) name of the user account, replacing Pretendco Administrator with the new user’s full name:

sudo dscl /Local/Default create /Users/pretendcoadmin RealName

"Pretendco Administrator"

4. Set the User ID (UID) as a unique value. In this example, run the following command to set the UID to 1100. Subsequent users will need additional unique UIDs.

sudo dscl /Local/Default create /Users/pretendcoadmin UniqueID 1100

5. Once a UID has been assigned to the account, set the default group ID (GID) using the following command. Note that the GID must be different than other GIDs but can be the same as the UID used in the previous step.

sudo dscl /Local/Default create /Users/pretendcoadmin PrimaryGroupID

1100

6. Now that the user has a GID, set the home directory for the user using the following command:

sudo dscl /Local/Default create /Users/pretendcoadmin

NFSHomeDirectory /Users/pretendcoadmin

7. Add the user to the existing admin group. If converting an existing user account into an administrative account, use only the following command:



sudo dscl /Local/Default append /Groups/admin GroupMembership

pretendcoadmin

8. Set (or change) the user’s password (unless it was a pre-existing account) using the following command:

sudo dscl . -passwd /Users/pretendcoadmin

Optionally, to avoid being prompted for it, the password may be included at the end of the command, as follows:

sudo dscl . -passwd /Users/pretendcoadmin newpassword

When generating a shell script from these commands, either prompt the user for the password in the script and use the entered value, or supply a hash/hash file instead. Otherwise the password would be available to anyone who knows how to edit a script.

Note: If you use this account for anything other than standard administrative purposes, you’ll want to populate the account with more attributes. In this case, you’re simply using a skeleton set of attributes given that the account doesn’t need to be fully usable.

Hiding a local accountIn many environments, you’ll want to hide the local administrative account. This can help keep users from deleting the account or attempting to escalate their privileges using the UID of the account.

To hide the new administrative account, first make sure to provide the account with a UID attribute that falls below 600 and isn’t assigned by the graphical interface. Those falling between 500 and 599 should not yet be in use. Then run the following command in a Terminal window:

defaults write /Library/Preferences/com.apple.loginwindow Hide500Users -

bool YES

Now log in and test that the account doesn’t show up in the Users & Groups System Preferences pane.

Note: When using hidden local administrative accounts, text input at login is allowed by default, rather than only showing a list of users. This is the default behavior of OS X when there are accounts able to authenticate but not listed in the login pane.



Making changes to the local administrative accountThe most common change to a local administrative account is altering the user’s password. To do so, use the dscl command with the passwd option.

In the following example, the -passwd option is used to change the password for the pretendco administrative account.

dscl . -passwd /Users/pretendcoadmin

Additionally, you can change items, such as the home directory or real name, by using dscl options.

Nesting network admins in a local administrative groupIf your organization doesn’t give help desk personnel access to local service accounts, and you want specific people in your organization to be able to administer local settings, install software, and perform maintenance locally on a client, you can give them local administrator rights through nested administrative groups. To do this, use the dseditgroup command to nest a network group into the local administrative group.

To nest a network group from Active Directory into the local administrative group:

1. Before nesting the Active Directory group, verify that it resolves correctly on the client. To do so, use the following dseditgroup command to resolve group membership,

dseditgroup -o read <active directory group name>

The “-o read” is the command for doing a read operation on the specified group. Therefore, if you run the command dseditgroup -o read mac_admins, you should receive the following output:

27 attribute(s) found

...

Attribute[5] is <dsAttrTypeNative:member>

Value[1] <CN=Ken Weaver,CN=Users,DC=pretendco,DC=com>

Value[2] <CN=Gary Dunn,CN=Users,DC=pretendco,DC=com>

...

As you can see from the above output, the member section lists group members. If you don’t receive the desired output, make sure you’re bound to a directory service and that the group exists within Active Directory.

2. Verify that OS X can resolve group membership for that group. Use the id command to see in which groups a user is included,

id <short name>

For example, if you run the command id jkaiser (assuming that jkaiser is in an administrative group), you’ll receive the following information:

uid=142413031(jkaiser) gid=63826092(pretendco\domain users)

groups=63826092(pretendco\domain users),

103(com.apple.sharepoint.group.3),104(com.apple.sharepoint.group.4),

98(_lpadmin),1166270692(pretendco\mac_admins),

102(com.apple.sharepoint.group.2),101(com.apple.sharepoint.group.1),

80(admin),20(staff)



3. To nest the Active Directory group, use dseditgroup with the -o edit option (edit operation), the -a option followed by the appropriate group name from Active Directory, the -t option followed by group (which specifies that the type to add is a group), and the -n option followed by /Local/Default, which specifies to add to the local directory service.

sudo dseditgroup -o edit -a <group name> -t group -n

/Local/Default admin

Using the above syntax, a sample of the command would appear as follows:

sudo dseditgroup -o edit -a mac_admins -t group -n

/Local/Default admin

If you receive a message about the group being upgraded, ignore this message.

Note: You can also add a network user to the admin group by using the same command but changing the type.

sudo dseditgroup -o edit -a <network user name> -t user

-n /Local/Default admin

Note: If you combine this with mobile (cached) accounts, you can give a user administrative rights to their local computer but allow for password policies managed from within Active Directory.

4. To test that the nested user is now a local administrator, open the Users & Groups System Preferences pane and unlock the pane with a user that is in the nested group. If it unlocks successfully, the user is now a local administrator.

Note: The command line utility used to run commands as root, sudo, doesn’t recognize nested groups. If you want users in nested administrative accounts to be able to use sudo, you must edit the /etc/sudoers file. Within that file, find the user privilege specification section, as follows:

# User privilege specification

root ALL=(ALL) ALL

%admin ALL=(ALL) ALL1

Then add %<AD group name> ALL=(ALL) ALL to that section. For example:

# User privilege specification

root ALL=(ALL) ALL

%admin ALL=(ALL) ALL

%mac_admins ALL=(ALL) ALL

Creating a local administrative account with a package or scriptThe local administrative account can also be created programmatically using a script, which can in turn be placed into a package. This process can then be automated. However, for the purpose of this example, you’ll create the local administrative account using a simple shell script, with a .bash suffix at the end.

To create a local administrative account using a shell script:

1. Open Terminal from /Applications/Utilities.

2. Create a file called createuser.bash using the touch command.



touch createuser.bash

3. Paste the following text into it:#!/bin/bash

dscl . -create /Users/hidden

dscl . -create /Users/hidden NFSHomeDirectory /Users/hidden

dscl . -create /Users/hidden RealName "Hidden Admin"

dscl . -create /Users/hidden PrimaryGroupID 499

dscl . -create /Users/hidden UserShell /bin/bash

dscl . -create /Users/hidden UniqueID 499

Each line in the script uses dscl (directory services command line) to create the user account and the user account attributes.

4. Since a password has not yet been assigned to the account, choose from three ways to provide a password for the newly created user.

The first way is to simply place the password into the script in clear text. This requires the directory services daemon to be running when the script runs. To do so, append the following line to the end of the above script:

dscl . -passwd /Users/hidden 'mypass'

The second, and most secure, way is to pregenerate the SHA1 hash and install it as a file with your package. This requires you to hard code the GeneratedID, which is typically automatically generated when the account is created using dscl using the standard iteration. The simplest method is to create a user and generate a password as described in the rest of this script. Then add the user’s corresponding plist file and the generated encrypted password file to a package and push it to the local workstation, also adding the GeneratedUID attribute in dscl. For example, if the GeneratedUID were 000-000-000 in a created account, the following would create the GeneratedUID when used as the last line of the script:

dscl . -create /Users/hidden GeneratedUID 000-000-000

Note: There are also scripts that can be leveraged to generate a SHA1 hash for the password as needed.

Binding to Open Directory using the command lineTo bind to an Open Directory environment from the command line, leverage the dsconfigldap command. Systems running OS X 10.6 and earlier will also need dscl to customize the search policy.

To bind to Open Directory from the command line:

1. Open Terminal from /Applications/Utilities. Once open, type:

dsconfigldap -a server.pretendco.com -u diradmin -p ldappassword -l

admin -q localpassword

In the above example, diradmin is the user name of the LDAP administrative account with a password of ldappassword, and admin is the local administrative user name with a password of localpassword.



2. To embed other information into the command, use the following options:

-f force authenticated binding/unbinding

-v verbose logging to stdout

-i prompt for passwords as required

-x choose SSL connection

-s enforce secure authentication only

-g enforce packet signing security policy

-m enforce man-in-middle security policy

-e enforce encryption security policy

-h display usage statement

The following parameters are necessary when automating the process in later modules:

-a servername add config of servername

-r servername remove config of servername

-n configname name given to LDAP server config

-c computerid name used if binding to directory

-u username privileged network user name

-p password privileged network user password

-l username local admin user name

-q password local admin password

3. The following command binds to the directory service using a user name and a password for both the local client and the directory service. The server was defined using the -a option followed by the server name of server.pretendco.com. The server’s administrative user that allows for binding was set using the -u option, followed by diradmin, the user of the server with said privileges.

dsconfigldap -a server.pretendco.com -l admin -q mypassword -u

diradmin -p myODpassword

4. By default, dsconfigldap adds the client to the search path. This can also be done manually (which is required in OS X 10.5 and earlier). To do so, add the Open Directory store to the search path and set the search path to custom for the computer to be able to authenticate against the bound directory. To set your search path to custom, use the following command:

sudo dscl /Search -change / SearchPolicy

dsAttrTypeStandard:LSPSearchPath dsAttrTypeStandard:CSPSearchPath

5. To set the third item in the search path, use the following command:

sudo dscl /Search -append / CSPSearchPath /LDAPv3/server.pretendco.com



6. To specifically bind and not add the new LDAP instance to the search path in OS X, use the -S operator along with the dsconfigldap command.

Binding to Open Directory using a postinstallation scriptAutomating Open Directory binding is fairly straightforward. Simply take the commands used to bind and run them in sequence within a file. For the purpose of this example, first create a file named ldapbind.bash using the touch command, which requires no options to run.

touch ldapbind.bash

Paste the following into the ldapbind.bash file for an authenticated bind. In this example, the user name for Open Directory is diradmin and the password is mypassword.

#!/bin/bash

dsconfigldap -a server.pretendco.com -n server.pretendco.com -u diradmin

-p mypassword

Alternatively, paste the following into the ldapbind.bash file (for an unauthenticated bind).

#!/bin/bash

dsconfigldap -a server.pretendco.com

dscl /Search -change / SearchPolicy dsAttrTypeStandard:LSPSearchPath

dsAttrTypeStandard:CSPSearchPath

sudo dscl /Search -append / CSPSearchPath /LDAPv3/server.pretendco.com

Given that some environments are more complicated than the above script, you may need to further customize the dsconfigldap script using more switches to denote items such as local administrative user names and passwords, SSL requirements, and packet signing requirements.

When performing a trusted bind with a password in the script, make the script self-destructing for added security. To do so, add a line at the end of the script that performs an srm (secure erase) of the script when it’s finished running. Alternatively, build a first-run launchd task into an image and have the launchd task remove itself when finished using the same srm command.

Binding to Active Directory from the command lineBinding to Active Directory can be done using the Active Directory plug-in from the command line. This is handled using the dsconfigad command. All of the options within the graphical user interface, described previously, are available in the command line and therefore they aren’t covered again here.

Basic use of the dsconfigad command only requires the inclusion of a computer name, a domain name, and the credentials for the domain name. In this scenario, you’re performing operations similar to those completed using the graphical interface, just using the Terminal application (in /Applications/Utilities).

dsconfigad -f -a mycomputername -u domainadmin -p domainadminspassword -

domain mydomain.com

To set up the mobile home directory for the Active Directory account to exist on the local system, add the -mobile switch to the end of the dsconfigad command with a setting of enable, as follows:

dsconfigad -f -a mycomputername -u domainadmin -p domainadminspassword -

domain mydomain.com -mobile enable



Other options available to the dsconfigad command include the following, broken out by type.

Basic options—commonly used

-computer

computerid

name of computer to add to domain

-force force the process (that is, join/remove the existing account)

-remove remove computer from domain

-localuser

username

user name of a privileged local user

-localpassword

password

password of a privileged local user

-username username user name of a privileged network user

-password password password of a privileged network user

-ou dn fully qualified LDAP DN of container for the computer (defaults to CN=Computers)

-domain fqdn fully qualified DNS name of Active Directory Domain

-show show current configuration for Active Directory

Advanced options—user experience

-mobile flag “enable” or “disable” mobile user accounts for offline use

-mobileconfirm flag “enable” or “disable” warning for mobile account creation

-localhome flag “enable” or “disable” force home directory to local drive

-useuncpath flag “enable” or “disable” use Windows UNC for network home

-protocol type “afp” or “smb” change protocol used when mounting home

-shell value “none” for no shell or specify a default shell “/bin/bash”

Advanced options—mappings

-uid attribute name of attribute to be used for UNIX uid field

-nouid generate the UID from the Active Directory GUID

-gid attribute name of attribute to be used for UNIX gid field

-nogid generate the GID from the Active Directory information



-ggid attribute name of attribute to be used for UNIX group gid field

-noggid generate the group GID from the Active Directory GUID

-authority enable

or disable

enables or disables the generation of the Kerberos authority

Advanced options—administrative

-preferred server fully-qualified domain name of preferred server to query

-nopreferred do not use a preferred server for queries

-groups "1,2,..." list of groups that are granted Admin privileges on local workstation

-nogroups disable the use of groups for granting Admin privileges

-alldomains flag “enable” or “disable” allow authentication from any domain

-packetsign flag “disable,” “allow,” or “require” packet signing

-packetencrypt

flag

“disable,” “allow,” “require”, or “ssl” packet encryption

-namespace flag “forest” or “domain,” where forest qualifies all user names

-passinterval

days

how often to change computer trust account password in days

-restrictDDNS disables the creation of a dynamic DNS record in Active Directory-integrated DNS environments

Binding to Active Directory using a scriptNow that you have done binding from the command line, you can automate the task in a fairly straightforward manner. To automate binding to Active Directory, create a simple script as follows. (Note: Replace the information in brackets <> with information matching your own environment.)

#!/bin/bash

dsconfigad -a <computername> -u <binduser> -p <binduserpass> -domain

<domain>

exit 0

Given that your environment is likely more complicated than the above script, you may need to further customize the dsconfigldap script using more switches to denote items such as admin user names and admin passwords.

Binding to Active Directory using a postinstall scriptTo use an Active Directory bind script as a postinstallation task during image deployment time, you have two options: make the script launch at startup, or place it into a package and add it to



your deployment scenario. With either option, you can set the script to automatically delete itself. For the purposes of this module, we will place the script in the /Library/StartupItems directory and call it adbind.bash.

1. To create the script, use the following command:

touch /Library/StartupItems/adbind/adbind.bash

2. Open the new empty shell script in your favorite text editor and paste the previously created script.

3. Once you have the script inserted, add a line at the bottom to remove the script and (optionally) provide an exit code. The whole script can be seen as follows:

#!/bin/bash

ipconfig waitall

dsconfigad -a <computername> -u <binduser> -p <binduserpass> -domain

<domain>

sleep 15

srm $0 /Library/StartupItems/adbind/adbind.bash

exit 0

Mapping UID, User GID, and Group GID using dsconfigadTo map UID, User GID, and Group GID, use the dsconfigad command with the -uid, -gid, and -ggid options. You can also use the -lu and -lp to insert the user name and password of the local user into the command. The following is the structure that should be used.

dsconfigad -gid <gid mapping> [-lu username] [-lp password]

For this example, you’ll map uid to the uidNumber in Active Directory. To do so, run the following command:

dsconfigad -uid uidNumber

Namespace support using dsconfigadThough not a recommended configuration, Active Directory has the capacity to allow two accounts to have the same user name, provided they are in different domains in the same forest. This can represent a namespace collision for OS X clients. To accommodate for this, the Active Directory plug-in allows you to set the forest and the domain independently, allowing you to specify which domain in a given forest against which to authenticate. Alternatively, dsconfigad can be used for the same purpose but provides the ability to authenticate to multiple domains within one forest by appending the domain name to your login credentials.

In this module, use the dsconfigad command to specify a domain and a forest.

By default, dsconfigad assumes the forest name is the same as the domain name, or only authenticates users as the domain specified at bind time. To allow the ability to log in using multiple domains within one forest, use the -namespace flag. The -namespace flag adds the domain name as a prefix to all accounts in the forest. Conflicting accounts from separate domains are addressed by binding each computer into the domain within which your account resides.

An example of the command to enable namespace support using the -namespace flag.

dsconfigad -namespace forest

Note: An unbind and rebind isn’t required to change these settings. They are global for all users on a Mac where this command is run.



Once run, use the domain name in front of the user name when authenticating. If you would like to switch to using domain namespace at a later date, you can specify the -namespace flag with domain as the setting.

To change namespace back, use the following command:

dsconfigad -namespace forest

Note: When run, the -namespace changes the primary ID for all accounts. Therefore, any user profiles for accounts from the Active Directory domain on each client computer need to be copied/moved into the new profile that is created.

Managing certificates from the command lineTo import certificates from the command line, use the security command. The security command contains many of the features in Keychain Access, including importing and exporting certificates. To simply import a certificate, use the security command along with the import option. For example, to import a certificate:

security import ~/Desktop/pretendco.p12 -f pkcs12

To trust the same certificate:

security add-trusted-cert -d ~/Desktop/pretendco.p12

To add it to the System keychain, thus making it available to all users:

sudo security add-certificate -k /Library/Keychains/System.keychain ~/

Desktop/pretendco.p12

The openssl command can be used to test connectivity to a server that requires the certificate, as follows:

openssl s_client -connect pretendco.com:389

Once you have validated that the certificate is functional, use dsconfigad to set the -packetencrypt option to ssl, as follows:

dsconfigad -packetencrypt ssl

Ignoring trust

By default, OS X requires that a certificate received from a domain controller be trusted. To modify this policy, you can configure the ldap.conf. To disable certificate verification, change the TLSR_EQCERT value by editing /etc/openldap/ldap.conf and changing the TLS_REQCERT setting to read never, rather than demand. By default, the settings read as follows:

#SIZELIMIT 12

#TIMELIMIT 15

#DEREF never

TLS_REQCERT demand

They should read as follows when complete:

#SIZELIMIT 12

#TIMELIMIT 15

#DEREF never

TLS_REQCERT never



Active Directory computer password changesThe Active Directory plug-in found in OS X supports the changing of computer trust account passwords for the Active Directory computer accounts on systems bound to Active Directory domains via dsconfigad. This module covers how to set up a workstation to rotate the computer trust account using a custom interval for changes.

The default time period of computer trust account passwords occurs every 14 days. Password change frequency is managed using the -passinterval flag followed by the number of days between each change. To set up your password interval to be 7 days rather than 14, use the following command:

dsconfigad -passinterval 7

The -passinterval option must be set after binding.

Viewing DFS with smbutilTroubleshooting connectivity issues with DFS can be a challenge, given that the root shares are obscured by a virtualization layer. To ease the process of troubleshooting DFS issues and to assist network administrators with scripting the end user experience, a tool called smbutil is included with OS X.

As the name implies, smbutil is used to interface with SMB servers. A common use of smbutil is to look at all of the referrals provided by a given host. To see whether a server hosts DFS referrals, use the dfs option with smbutil followed by the path to the server. For example, for test.pretendco.com, use:

smbutil dfs smb://test.pretendco.com

The output will contain the expanded name of the server (the name prefixed by the hostname). The listing will also display the single-line domain name.

Adding each portion of a DFS path to the connection string will show more in-depth information about that portion of the DFS root. The previous server is a mobile home directory server. As such, it has a share called HomeDirectories. Using the command smbutil dfs smb://test.pretendco.com/DFS will show the paths and referrals for each share that is part of a namespace server we called DFS (as can be seen here):

Referral requested: /WIN-MIE2GCGNMU0.test.pretendco.com/DFS

list item 1 : Path: /WIN-MIE2GCGNMU0.test.pretendco.com/DFS

list item 1 : Network Address: /WIN-MIE2GCGNMU0/DFS

list item 1 : New Referral: /WIN-MIE2GCGNMU0/DFS

To see the referrals available for each namespace within:

smbutil dfs smb://test.pretendco.com/DFS/HomeDirectories

The output will end with a number of lines that show referral information:

Referral requested: /WIN-MIE2GCGNMU0.test.pretendco.com/DFS/

HomeDirectories

list item 1 : Path: /WIN-MIE2GCGNMU0.test.pretendco.com/DFS/HomeDirectories



list item 1 : Network Address: /WIN-MIE2GCGNMU0/DFS/HomeDirectories

list item 1 : New Referral: /WIN-MIE2GCGNMU02/DFS/HomeDirectories



The user name and password can also be added into the smbutil options, for testing purposes. The following example shows this, using testuser as the user name from Active Directory and testpassword as that user’s password.

smbutil dfs smb://testuser:[email protected]/DFS/HomeDirectories



OSX ML TT Integration

Documents

Transcript of OSX ML TT Integration