Here is the scenario: You manage a Windows Server 2008 Active Directory domain that includes both Windows 7- and Mac OS X-based client computers.
Anyone who has ever had to manage systems on a network typically finds the tools and commands necessary to perform administrative tasks across the board that suit their type of computers. For example, Microsoft sys admins are encouraged to use PowerShell to implement management of Windows-based hosts.
![]()
However, the days of homogeneous networks is quickly coming to a close. The BYOD push is flooding networks with everything from various Linux distros to iOS and Android operating systems — heterogeneous networks are growing in a big way.
One increasingly common trend amongst those mentioned above are SMB switching over to Apple computers for their native support of OS X, Windows, and other operating systems. Similar to how a Windows desktop would join an Active Directory domain, Macs also offer binding to several directory-based domains for central management of nodes.
And while Apple does have their own Open Directory rolled into OS X Server, it has gotten better in its support of other standards-based directory binding — though there are still a few hiccups that cause for a breakdown in communication. And sometimes, these breakdowns can be downright frustrating behaviors from Apple computers bound to Active Directory domains.
![]()
Let's take a look at a few of the more general errors, along with causes, and how to resolve them in little to no time.
1. Pre-stage the account in Active Directory (AD)
Symptoms: Trying to bind OS X to Active Directory produces errors that the account or object cannot be found.
Causes: In most cases, this comes down to a communication error between the client (OS X) and the directory server (AD). Further investigation could reveal if the issue lies with DNS not forwarding requests properly or perhaps a network configuration issue. Other times, it may be a permissions issue between the account being used to bind machines and/or permissions to add or modify objects within AD.
Solution: Aside from network configuration issues, such as separate subnets or VLANs, pre-staging computer accounts in Active Directory is one of the quickest and easiest fixes to objects not being found. Start by manually creating the computer object in the desired Organizational Unit (OU) prior to attempting to bind any Macs to AD. Once AD has replicated across the organization, try binding again.
By creating the pre-staged object, relevant DNS records and network settings now have an endpoint to target when attempting to bind. Especially if the access level of the account used to bind may not have domain admins or enterprise admins-level status, it may be enough to bind OS X to the directory and populate the object with the information pertaining to that particular Mac.
2. Allow network users to login
Symptoms: Apple computer will not allow users to authenticate to the AD server, thus preventing logon.
Causes: Loss of connectivity to the network or systems configuration changes have been made, limiting access to local accounts only.
Solution: 99% of the time, experience has taught me to check the network cable/Wi-Fi power status first. Once connectivity has been verified, the next step is to ensure that the checkbox next to Allow network users to log in at login window has been checked. A further step to review is to click the Options.. button next to it and verify that all users that should be allowed access to login are whitelisted.
3. Active Directory Search Policy
Symptoms: User cannot login with AD credentials as the computer processes the account until it times out or shakes 'no' as if an invalid password was entered.
Causes: Sometimes it is, in fact, an incorrect password. Other times, when the Mac is initially bound to the domain, it will automatically populate certain fields of information, such as the Search Policy, which dictates what domain(s) the AD plug-in will look to in order to authenticate the account. The populated Search Policy is usually correct, but as is common within forests of multiple domains, the wrong entry may be set as the default.
Solution: Access the Directory Utility, System Preferences | Users | Login Options, then click the Edit.. button, and select the Open Directory Utility.. button. From here, you can view the entries in the Search Policy by clicking on the Search Policy tab and use the '+' or '-' buttons to add/remove entries to point to the correct domain to which the Mac is bound.
4. Configure directory settings for AD plugin
Symptoms: Similar to above, users cannot login with AD credentials as the computer processes the account until it times out or shakes 'no' as if an invalid password was entered.
Causes: OS X binds to AD using default settings of maximum compatibility. However, specific settings may be required in order to ensure that the client communicates with the correct AD server. These settings need to be modified manually or scripted.
Solution: Clicking on Services in the Directory Utility and selecting the Active Directory service allows users to modify the settings used by the service to specify network protocols, custom attributes, and (most importantly) preferred domain servers, adding administrative security groups to manage the client or allowing authentication from any domain in the forest. This is accomplished by simply check marking the entries you wish to modify and entering the relevant information.
5. Check DNS name
Symptoms: Difficulty communicating on the network with other computers or Wake-on-LAN (WOL), though internet access work just fine.
Causes: Changes in computer name are frequently attributed to changes in network access. For example, a Mac named 'MAC-FU' may suddenly rename itself to 'MAC-FU (1)' when it detects a 'ghost' of itself on the network or another computer with the same name. Changes from one subnet to another will sometimes trigger a name change like this to prevent both desktops from going offline. Also, when desktops are bound to the domain, unbound and then rebound, they will sometimes cache the DNS information and rely on that during rebinding. This can cause a newly renamed computer, say 'MAC-123.domain.com' to have a DNS hostname of 'MAC-456.domain.com,' which is its previously bound name.
Solution: Check the computer name by going to System Preferences | Sharing and verify that the computer name listed is the same as the name entered when the computer was bound to the domain. Additionally, clicking the Edit.. button will bring up the local hostname. If these two entries are different (as in the example above in the Causes section), then unbind the machine and modify the computer name and hostname so they are the same, reboot the computer, and then bind it again to Active Directory. This should resolve any DNS-related issues to reflect the proper name — both locally and on the directory server.
This is not, by any means, a comprehensive listing for troubleshooting Mac-AD connectivity issues. As with any software, the sad truth is that there are seemingly endless possibilities for certain products to malfunction or outright fail that make troubleshooting sometimes incredibly difficult.
Troubleshooting is, in my opinion, a sacred art. It is what allows us to resolve the problems of the technical world around us without being a developer or an engineer for that specific product. At the same time, with product offerings, such as ADmitMac and Centrify, directly from developers and engineers and aimed directly at tackling such issues head on, perhaps a software-based solution is a better fit for the specific needs of your specialized network.
What other common troubleshooting tips and tricks do you recommend when working with Active Directory? Share your experience in the discussion thread below.
Os X Active Directory
Editor's note: When originally published this article said that by using dynamic user identification (UID) generation, users might be assigned a different UID number each time they logged onto a different Mac. We have confirmed with Apple that this is no longer the case; the story is corrected below.
Supporting Mac users can be a challenge to systems administrators in a Windows Active Directory environment. Although Apple has used Samba to make it easy for Macs to browse and access shares and printers hosted by Windows servers using Microsofts server message block (SMB) protocol, true Active Directory integration requires more than just access to resources.
For one thing, it requires support for an environment where users can rely on their Active Directory accounts for log-in to both Mac and Windows computers. Depending on your environment, you may also want to be able to implement security measures to limit what users may do while logged into a Mac or to manage the user experience as you would do with group policies for Windows machines.
There are a number of solutions and approaches that you can take for integrating Macs into your Active Directory infrastructure, and I'll be talking about some of them here.
Apples Active Directory plug-in
The lowest-cost solution is to use Apples built-in Active Directory support. Beginning in Mac OS X Panther (10.3), Apple introduced a plug-in to its Directory Access utility that allows you to configure authentication against Active Directory. Apples Active Directory plug-in uses LDAP to query Active Directory.
The Active Directory plug-in works fairly well. It supports forests with multiple domains, domain controller fail-over and can automount a users home directory. It can also grant users administrator access to a Mac workstation based on their Active Directory group membership. You can also enable mobile accounts for portable computers and designate a preferred domain controller if needed.
The process of using the plug-in to join a Mac to an Active Directory domain is straightforward, and is similar to joining a Windows computer to a domain. Youll need an Active Directory account with permission to join the computer to the domain; if the account was not created in advance, youll need authority to create it. You will also need to configure the search path of available directories to include Active Directory using the Authentication tab in the Directory Access tool. Mac OS X can search multiple directory configurations in a specified path when a user attempts to log in.
Dynamic UID vs. static UID mapping
One of the hurdles to integrating Mac OS X with Active Directory is that their directory services schemas are significantly different. One of the key attributes in the Open Directory schema used by Mac OS X is the User ID number (UID). As in other Unix systems, the UID is used by the Mac OS X file system to designate file ownership and permissions both for local and remote files.
Each local or network user account used to log into Mac OS X requires a UID. But there is no directly correlating attribute in Active Directory.
Active Client For Mac Downloads
Apple provides a choice of two methods to providing Active Directory users a UID attribute. The first and default option is to dynamically generate a UID for each user when they log in. When this option is used, Mac OS X generates a UID at login based on the GUID (Globally Unique Identifier) attribute from the users Active Directory account. Verbal assistance with windows for mac client. The second option is to choose an attribute that is included in Active Directory as the users UID. You can map any attribute, be it one that is part of the default Active Directory schema or one that is part of a custom schema extension.
Using a static UID by mapping it to an attribute in Active Directory may prevent potential issues and it may be a solution that you have already implemented for other Unix systems in your network. However, it requires more effort. If you choose to map to an existing attribute, you will need to manually populate this number in each user account that will be used for Mac login. This can be a tedious process. If you choose to use an existing attribute rather than extend Active Directorys schema, youll lose the ability to use that attribute for another purpose.
Os X Active Directory Integration
Thursbys ADmitMac
ADmitMac by Thursby Software Systems offers several features that Apples Active Directory plug-in and Samba configuration do not. Like Apples solution, ADmitMac is based around a Directory Access plug-in.
Most notably, ADmitMac fully supports Kerberos under Active Directory as well as signed LDAP and SMB communication and NT LAN Manager, enabling much tighter security with Windows 2003 Server. As such, it doesnt require you to lower the default security settings of Windows 2003 Server. Apples solutions require unsigned LDAP and SMB communication.
In addition to enhanced security, ADmit Mac supports the Windows Distributed File System and long share names, and provides additional options for browsing a Windows Server network for shares and printers. A specialized version is also available with support for the Common Access Card smart card standard.
ADmit Mac also provides some other advantages. First, it offers an Active Directory management console for Mac OS X that allows administrators to reset user passwords, move users and computers and create or modify existing accounts much as they would using the Microsoft Management Console. Second, it offers more options than Apples solution for how network and local home directories are managed. Particularly helpful on this front is a tool that can be used to move a local Mac users home folder to a network location and associate it with an Active Directory account. This can make the transition to Active Directory integration much easier for end users.
Also, ADmitMac supports an Apple-managed client environment. Like group policies in Active Directory, Mac OS Xs managed client environment -- sometimes referred to as MCX -- allows administrators to restrict access to Mac OS X system components and to create a highly customized user experience. ADmit enables several of Apple's client management features and does so using Mac OS X Servers Workgroup Manager.
To do so, ADmit Mac creates a file stored on a Windows share within the domain to hold all the MCX user information that would normally be stored in an Open Directory domain hosted by Mac OS X Server. However, Thursbys own documentation admits that its client management approach isnt perfect and that some actions may result in unexplained error messages or simply may not function without any indication of an error.
Centrifys Direct Control for Mac
Centrifys Direct Control is a series of solutions for integrating diverse platforms with Active Directory, including Mac OS X.
Direct Control installs as a Directory Access plug-in under Mac OS X. When the server-side solution is installed on Windows domain controllers, it adds a series of group policy objects (GPOs) that can be used to manage the Mac environment. Direct Control offers a range of GPOs for security and user experience settings -- many of which mirror the options available using Mac OS X Servers Workgroup Manager tool. It does this by integrating a local registry file copied to the Mac with Apple's MCX architecture. Direct Control also offers the ability to use smart cards for authentication.
Direct Control offers the simplest and most full-featured Active Directory integration solution for Mac OS X. Because it relies on Active Directorys group policy architecture, it functions more seamlessly for managing access than does Thursbys ADmitMac, particularly for systems administrators who are unfamiliar with Mac OS X.
Also impressive: It succeeds without modifying the Active Directory schema. It does not, however, offer the security of signed SMB connections, although it does support encrypted LDAP queries. It also works well with products such as Thursbys DAVE to enable signed SMB communication as well as with third-party server-side solutions that support Mac OS Xs Apple Filing Protocol, which offers greater security than unsigned SMB.
Using Mac OS X Server for additional client management
If you want to take full advantage of Apples client management architecture, the best solution is to implement Mac OS X Server in your Active Directory environment. This can be the most challenging method of adding support for Mac OS X because Active Directory and Open Directory, Mac OS X Servers native directory service, have very distinct schemas. They also share three matching attributes: username, password and home directory. This can make creating a fully integrated infrastructure a very big challenge because it requires extending the schema of one or both platforms.
There is a method of offering partial Mac client management and access to other Mac OS X Server services under Active Directory that doesnt require schema modification. The approach is twofold. First, join Mac servers and clients to Active Directory using Apples Active Directory plug-in. Second, create a directory search path on Mac servers and clients that searches both the Active Directory domain and an Open Directory domain hosted by one or more Mac servers.
This configuration allows you to create computer lists in the Open Directory domain that contain Mac computer accounts from Active Directory. Management settings can then be enforced on those computer lists using Mac OS X Servers Workgroup Manager with no further configuration.
The same approach can be extended to groups of users by creating group accounts in the Open Directory domain and populating them with user accounts from Active Directory. This method isnt perfect, and some client management functions may not respond properly, but it requires significantly less effort than modifying the Open Directory and/or Active Directory schemas. It can function as a temporary solution if you are planning to extend the schema but require an immediate solution while you do so.
What about Services for Mac?
Windows Server includes Services for Mac (SFM) -- optional components that provide the ability to create and manage shares and print queues using the Apple Filing Protocol (AFP) and the defunct AppleTalk protocol. Services for Mac is a solution that was designed to work with the classic Mac OS versions -- in other words, those before Mac OS X.
Sonicwall global vpn client for mac download. Its security options rely on a Microsoft user authentication module being installed on Mac clients, a version of which was never developed for Mac OS X. As such, the only way to support Mac OS X access to SFM shares and print queues is by using clear text passwords or the limited encryption of an older version of the AppleShare protocol.
Given Apples longstanding inclusion of Samba in Mac OS X and the security limitation, it has been quite some time since SFM was considered a terribly solid solution. SFM also suffers from performance issues because of its design and the fact that it relies on the outdated AppleTalk protocol.
That said, there are alternate third-party AFP servers for Windows Server, including the robust ExtremeZ IP by Group Logic and MacServerIP by Cyan Software.
These products offer enhanced security options but they also offer one other feature that can be important for some Mac users. Mac files contain a resource fork as part of their structure; this fork is not supported by either NTFS or FAT file systems. When working with SMB-mounted drives, Mac OS X typically performs a translation of the resource fork into a separate file to work around this issue.
For most applications, this functions very well. However, some applications encounter problems with this approach. In those situations, having an AFP server solution can result in a more seamless workflow.
Ryan Faas is a freelance writer and technology consultant specializing in Mac and multiplatform network issues. In addition to writing for Computerworld, he is a frequent contributor to InformIT.com. Ryan was also the co-author of O'Reilly's 'Essential Mac OS X Panther Server Administration.' You can find more information about Ryan, his consulting services and recently published work at www.ryanfaas.com and can e-mail him at [email protected].
Mac Os X Active Directory
Copyright © 2007 IDG Communications, Inc.
Active Directory For Mac
Sponsored Links
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |