OSX ML TT Integration

This document is intended for Apple internal and channel audiences, and is for training purposes only.
OS X Mountain Lion
Technical 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 Apples
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 confidentialfor 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 confidentialfor 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 confidentialfor internal and channel use only iv
Introduction
This 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 organizations 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 series
This 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 confidentialfor internal and channel use only 1
1 Directory Services
A 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 isnt 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 services
Local 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 youre 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 theyre 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, its often safer to edit with directory
services command line utilities. When you edit property list files directly, files arent checked for
errors and changes arent 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:
odutilMonitors directory services and manages directory services logging.
dsclDirectory Service command line utility
dscacheutilLooks up information, flushes caches, and gathers statistics on directory
services.
dseditgroupAlters group membership information.
dsenablerootEnables or disables the root account.
dserrShows descriptions of directory services error codes.
dsexportExports directory services information.
dsimportImports directory services information.
dsmemberutilChecks group memberships and UUIDs and performs specific debugging
operations.
idValidates user and group information.
Creating local administrative accounts
Frequently, 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 administrators
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 users 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 Directory
Open 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 theyre running on must be bound to Open Directory.
Setting up an Open Directory master
In 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 servers 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 systems 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 cant
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 cant 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 organizations name and an administrators
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 youre 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 Directory
For 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, youll learn how to bind to an Open Directory server.
Before beginning this exercise, youll 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 doesnt respond, it may be because its 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 Preferences
The 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 youre 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 dont 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 isnt already trusted, youll be
prompted to trust the SSL certificate.
8. Click Trust.
If the LDAP communication isnt encrypted, youre 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 operations
If 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 doesnt 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 youre 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 youll 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 replica
After youve configured the Open Directory master, its 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 Directory
Active Directory is Microsofts 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
Directoryspecific 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 cant extend
their AD schemas so third-party solutions can provide policies to Mac computers without
extending the schema.
In this section, youll learn some administrative tasks for managing OS X with Active Directory.
Binding to Active Directory
You 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 doesnt 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 youll 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 youve 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 havent 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 users 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 information
Before 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, youll 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
users 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 doesnt 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 isnt 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, dont use ls to list the contents of the User node. Instead
type read <ad username> to view that users 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 cant read the attributes for a user, check access controls in Active Directory and make
sure that youve 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 users 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 jfoster@PRETENDCO.COM:
4. If there are no errors, type klist to see your ticket. If there are errors, investigate and
remedy them.
bash-3.2$ klist
Ticket cache: /tmp/krb5cc_ttypa
Default principal: jfoster@PRETENDCO.COM

Valid starting Expires Service principal
03/07/13 19:49:21 03/08/13 05:49:19 krbtgt/jfoster@PRETENDCO.COM
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 its 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 its
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 jfoster@pretendco.com).
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 wasnt found, open Directory Utility and
check the settings for your Active Directory configuration. If you havent selected Force local
home directory on startup disk, theres 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 youre 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 isnt 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 youre 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 OUsuch 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 cant look up a single account, the Active Directory connection isnt 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 cant cd into All Domains, you cant 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, dont enter ls to list the contents of the node, but rather use read to read the
attributes of that user.
If you cant 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 users password doesnt work, make sure that you dont 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 Utility
OS X identifies a user on the system with a Unique ID, or UID. The UID determines a users 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, its 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 dont
contain the UID and GID values. If youre 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 youre unsure, consult with your Active Directory administrator about what values would be
appropriate for this purpose. If these values arent 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 arent 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 its
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 arent sure
what values to enter, ask your Active Directory administrator.
11. Click OK to apply the changes.
Setting a user home directory
Active 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 isnt
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 cant 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 options
You 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 its being exchanged with Active
Directory. Configuring packet signing options is a policy thats 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 its 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
doesnt 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 instructions
Environments 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 isnt 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.
LDAP
Lightweight Directory Access Protocol (LDAP) is the protocol used in most modern directory
services systems, including Novells eDirectory, Microsofts Active Directory, and Apples 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 databasecalled 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 LDAP
To 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 binding
Binding a Mac computer to an LDAP server with a simple bind tells the directory services
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.
Youll 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. Select the Enable checkbox to enable the LDAP connection.
5. Enter a name for the configuration in the Configuration Name field.
6. Enter either the host name or IP address of your LDAP server in the Server Name or IP
Address 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 youre
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 binding
Use 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 its 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 attributes
In 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 dont 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 youve entered a record, you can see that if you have 30 records and 100 systems, its
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 theyll 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 servers /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.
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.
Kerberos
Kerberos is a network authentication protocol that provides a client-server architecture where
mutual authenticationboth the user and the serververify each others 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 services private key. If a client presents an invalid or
unverified service ticket to the service, the clients 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 hosts 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 its important to
know that when a user first authenticates to a KDC (whether its 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 Collaboration
One 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 organizations existing collaboration solutions.
In many organizations, collaboration revolves around accessing groupware and corporate micro
sites that are centered around Microsoft servers. In this section youll learn how to access
Microsoft Exchange, connect to Microsoft SharePoint and DFS shares, and communicate with
instant messaging servers.
Microsoft Exchange integration
Starting with Microsoft Exchange 2007, the Exchange Web Services (EWS) application
programming interface (API) was designated Microsofts next-generation API for collaboration
services. Its 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 shouldnt 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 isnt preferable for most organizations.
Using Mail, Calendar, and Contacts with Exchange
There 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 users 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 hasnt been configured with any accounts, the Welcome to Mail dialog will prompt
you to add an account.
3. Enter the users 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 users 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 isnt 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 doesnt 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 Mail
Setting 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, youll 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 Exchange
Most 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.
DNS
Many 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 havent been configured on the DNS servers, the Mac
client cant 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 errors
If 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 size
Microsoft 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 doesnt 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).
Troubleshooting Microsoft Outlook 2011
Microsoft 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 isnt 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 theres 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 SharePoint
Microsoft 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 isnt yet bound to the Active Directory domain or if the
SharePoint Server isnt yet kerberized to the domain.
If youre 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 isnt
supported by OS X.
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 shares
Distributed 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 youre using Kerberos, and you have permission to connect to the share, a window with the
shares contents appears. If youre not using Kerberos, youre prompted to enter a password.
Enter the user name and password.
5. Click Connect.
Instant messaging
OS X supports many standard instant messaging platforms. In the following section, youll learn
about Messages, FaceTime, and integration with Microsoft Office Communications Server as
potential instant messaging clients.
Messages
Messages 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, its 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 youve 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 iOS
Apples 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.
FaceTime
You can use FaceTime on your Mac to make and receive video calls with users on any device that
supports FaceTimeanother 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
computers 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 dont 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 youve 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 youre 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 youre 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 youre 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 cant
be used to initiate a video call:
Verifying: The email address hasnt 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 couldnt be validated. This situation can occur if the email address
is already associated with an Apple ID being used with FaceTime.
Microsoft Office Communications Servers
The 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.
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 dont 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.
Resources
Command line help: man pages
For 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/server/macosx/resources/documentation.html.
Third-party Active Directory plug-ins
Although 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 youre not able to extend your schema for policy objects specific to OS X, third-party plugins
may help provide those features.
Centrifyhttp://www.centrify.com/directcontrol/overview.asp
ADmitMachttp://www.thursby.com/products/admitmac.html
Dellhttp://www.quest.com/authentication-services/
PurpleRagehttp://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:
Thursbys DAVEhttp://www.thursby.com
DAVE doesnt 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 Thursbys AdmitMac for Active Directory authentication, but DAVE doesnt
require AdmitMac and it can be used with the Active Directory plug-in built into OS X.
Sharityhttp://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.
GroupLogichttp://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 GroupLogics client application to query the ExtremeZ-IP web services running on a
Windows server.
Exchange troubleshooting resources
The 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 Information
There 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 Server
For 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 Guys blog
entry for adding XMPP services:
http://www.ocsguy.com/2010/11/29/deploying-lync-for-xmpp/
Microsoft SharePoint information
Microsoft 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
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
Appendix
This 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 line
A variety of user administrative tasks cant be completed using the OS X graphical user interface
(GUI), including customizing the location for a users 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 users 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 users 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, youll
want to populate the account with more attributes. In this case, youre simply using a skeleton set
of attributes given that the account doesnt need to be fully usable.
Hiding a local account
In many environments, youll 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 isnt 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 doesnt 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 account
The most common change to a local administrative account is altering the users 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 group
If your organization doesnt 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 dont
receive the desired output, make sure youre 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), youll 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, doesnt 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 script
The 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, youll 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 users 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 line
To 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 servers 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 script
Automating 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 its 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 line
Binding 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 arent
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, youre 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 optionscommonly 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 optionsuser 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 optionsmappings
-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 optionsadministrative
-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 script
Now 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 script
To 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 dsconfigad
To 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, youll map uid to the uidNumber in Active Directory. To do so, run the
following command:
dsconfigad -uid uidNumber
Namespace support using dsconfigad
Though 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 isnt 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 line
To 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 changes
The 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 smbutil
Troubleshooting 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 users password.
smbutil dfs smb://testuser:testpassword@test.pretendco.com/DFS/
HomeDirectories

OSX ML TT Integration

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

OSX ML TT Integration

Caricato da

Copyright:

Formati disponibili

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

For Exchange 2007, the Web.config resides in \Program Files\Microsoft\Exchange

Potrebbero piacerti anche