ADmitMac ® turns a Mac into a true Active Directory client. Today, a decade after becoming the world's first non-Windows Active Directory integration product, ADmitMac is a one-stop solution for Mac-Windows management and security needs, ensuring compliance with standards such as SOX, PCI DSS, FFIEC, HIPAA or HITEC. Active Directory management, migration, compliance, auditing and security. These solutions work across Unix, Linux, Mac OS, Java and other business applications. With more than 149 million accounts managed, 101 million accounts audited and 86 million accounts migrated, Quest is the clear leader when it comes to AD. Active Roles.
Over the years, the terms Magic, Golden, Triangle, Augments, Directory, Domains and Active have given the administrators of Mac OS X environments fits. So when you think about using Active Directory to manage iOS devices through the Profile Manager service, built into Lion Server, you may think that it’s a complicated thing to piece together. You may remember those days when you had to manually craft service principals because xgrid wouldn’t play nice with Acive Directory, or you might think of twisting augmented records to support CalDAV. But you’re gonna’ have to forget all that, ’cause getting Profile Manager to talk to Active Directory is one of the easiest things you’ll do. Before we get started, architecture. Every Profile Manager instance is an Open Directory Master.
Apple has included a local group in Mac OS X Server called Profile Manager ACL. Users and groups from any directory domain that can be viewed in dscl can be added to this group. Adding objects to this group enables them to authenticate to the MyDevices portal but not administrate. Kerberos isn’t really used here, nor are nested groups. You’ll apply policies directly to Active Directory groups in Profile Manager. For many long-term Apple administrators, this paragraph is all you need to read.
If not, please continue on. To get started, first set Profile Manager up,. Once configured, verify that Open Directory or local clients can authenticate, bind to Active Directory. Bind to Active Directory From within System Preferences, click on the Users & Groups System Preference pane and click on Login Options. Then click on the Edit button for the Network Account Server.
From here, click on the plus sign (“+”) and enter the domain name into the Server field. Once bound, you will see the server listed. At this point, if you try to authenticate to the MyDevices portal as an Active Directory user, you will be able to authenticate, but you will not have permission to enroll devices. To log in, access the web service at the address of the server followed by /MyDevices (e.g.
Provide the user name and password to the service. The Active Directory users are unable to access the MyDevices service.
Nest Groups Using Workgroup Manager Click on Logout and we’ll fix this. There is no further configuration required for the Active Directory groups to function properly in regards to how they work with the server. However, we will need to open Workgroup Manager and nest some groups. You might think that you’d be doing something all kinds of complicated, but notsomuch. You also might think that you would be nesting the Active Directory users and groups inside Open Directory groups, given that you have to enable Open Directory in order to use Profile Manager.
Again, notsomuch. To nest the groups, browse to the local directory and then then click on the com.apple.accessdevicemanagement group. Click on the lock icon to unlock the directory domain, authenticating when prompted. Click on the Members tab and then click on the plus sign (“+”) to add members to the group. Then in the menu that slid out, click on the domain browser at the top of that menu and select the Active Directory entry. Test Access Drag the user or group from the menu into the list of members and then click on the Save button. Now log in again using the MyDevices portal and you’ll be able to Enroll.
From within Profile Manager (log in here as a local administrator), you’ll see all of the users and groups and be able to apply policies directly to them by clicking on the Edit button for each (the information isn’t saved in the directory service on the server, but is cached into the directory service client on the client when using Mac OS X 10.7, Lion based clients). Moving Mac OS X Management From MCX You keep hearing that you need to move some of your managed preferences to profiles (or Profile Manager in most cases), but you can’t really think about that until you get Profile Manager integrated with Active Directory, can you? And getting those pesky iOS devices working with Active Directory style policies has been on your radar, but really, who has time?
Then have a few distinct benefits over Managed Preferences (MCX) for some, which we’ll look at through the lens of Profile Manager. The first is that they’re instant. You can make a change to a profile on a device enrolled in an MDM service and you instantly see the changes on the client (most profile settings that is, not all), rather than having to log the client out and then back in. You can also wipe and lock devices and the interface is easier (I mean, no nesting thankyouverymuch). But there are a few drawbacks as well.
You can’t cluster Profile Manager, so there are some benefits to using 3rd party services in a move to profile based management. You also manage settings using the Always option, rather than being able to use the Once or Often settings. You can use custom property lists, though and importantly, MCX is used to actually implement most of these profiles on client systems, so those skills you’ve been honing for managing Managed Client workflows will not be totally lost in the transition. Overall, I had initially thought that management by profile would be much less granular than management via managed preferences, but I’ve found ways around any issues and have found it’s actually much easier and works as reliably as dual directory or Active Directory based managed preferences worked.
Thanks for the helpfull hints. Unfortunately, we are still seeing funkyness when binding to a.local AD domain. Centrify have a great troubleshooting guide at Unfortunately, even with these steps we still see authentication working for some time (hours), then suddenly stopping, only to work fine again after a reboot. “id ” and “login ” seem to work during these episodes, and dscl list /Active Directory allows browsing of the domain. I think I’ll be spending some time in the directory debug log. Does anyone have any input on the following problem?
My Lion Server Profile Manager refuses to cooperate after I’ve deployed 1500 macbooks. The profile is there and working but it will not load that profile so that I can make changes to it and push to clients.
Can I add modifications to MCX settings and apply those to an AD group basically can I use the profile and MCX settings without harm. Any advice here would be useful. I find profile manager to be the most frustrating apple product I’ve ever used. I tried to do it their way but have had no luck getting ruby and profile manager to work after I deployed my client machines.
Active Directory is Microsoft’s directory services solution that provides LDAP and Kerberos services for identification and authentication. Many organizations with Windows computers use Active Directory because it provides these features:. Security and policy management for Windows computers. Tight integration with popular application servers such as Microsoft Exchange and Microsoft SQL Server. High availability, with the ability to place multiple replica servers across geographic locations in a multimaster configuration It is easy to integrate Mac OS X into an Active Directory environment. In the Active Directory Domain field, type the name of the Active Directory domain—in other words, “pretendco.com” not “windows-server.pretendco.com.” This can be any domain in the forest, but remember that the domain name is the DNS namespace of the domain, not the DNS name of the domain controller.
In the Computer ID field, type the name of the Active Directory computer object to use for this Mac OS X computer. In the AD Administrator Username field, type the name of an Active Directory administrator or the name of an Active Directory user who can join a computer to the domain.
In the AD Administrator Password field, type the password for the user you specified in step 9. Mac OS X attempts to bind to Active Directory with the default settings. Logging In as an Active Directory User on Mac OS X Once you bind your Mac OS X computer to Active Directory, you can log in with your Active Directory user account at your Mac OS X login window. The following figure shows the default desktop for an Active Directory that logs in to a Mac OS X computer. Note that the home folder is located on the startup disk (Option-clicking the name of a folder in the title bar of a Finder window reveals the path to the folder). The user launched the Kerberos application (in /System/Library/CoreServices), which shows that Mac OS X obtained a Kerberos ticket-granting ticket (TGT) for the user as part of the login process. At the Mac OS X login window, you can use many combinations of the user identifiers “Full name,” “User login name,” or “User login name (Pre-Windows 2000)” from Active Directory, along with other elements of the domain name.
Consider the figure at left, which shows a user created with Active Directory tools. You can log in with any of the following names in the Name field in Mac OS X’s login window:. schoun-regan. sregan. Schoun Regan. schoun-regan@pretendco.com.
sregan@pretendco.com. Schoun Regan@pretendco.com.
PRETENDCO schoun-regan. PRETENDCO sregan. PRETENDCO Schoun Regan Understanding the Home Folder Default Behavior When you log in with a user account for Active Directory, by default Mac OS X creates a home folder for the user on the startup disk in /Users/ usershortname. If a directory already exists with that name, Mac OS X will not create a new home folder. You may experience unexpected results because the Active Directory user does not have write permissions to the home folder. See “Transitioning from a Local User to an Active Directory User,” later in this chapter, if that is appropriate for your situation.
Understanding Home Folder Synchronization The default settings do not configure Mac OS X to synchronize the local home folder with a network home folder. If you log in as the same Active Directory user on multiple Mac OS X computers that are configured with the default settings for the Active Directory plug-in, you will have a different home folder on each computer, and the contents will not be synchronized. To prevent this situation you can do the following:. Configure mobile accounts and home folder synchronization. See “Understanding Mobile Accounts” for more on this. Deselect the option to force the creation of a local home folder, and use Active Directory tools to assign a network home folder for the Active Directory user account. See “Specifying a Network Home Folder” for details.
Changing the Active Directory Plug-in Default Settings The Active Directory plug-in’s default settings might not meet your needs. For instance, you may want to not force local home folders on the startup disk, or you may want to use custom mappings or to specify Active Directory groups to members that have local administrative access on your Mac OS X computer. In this section you will learn how to use Directory Utility and the command line to configure some of the advanced options of the Active Directory plug-in.
Follow these steps to use Directory Utility to access Active Directory Advanced Options:. Open Directory Utility. If necessary, click the lock in the lower-left corner and provide credentials for a local administrator. If necessary, click the Show Advanced Settings button in the lower-right corner of the Directory Utility window. Click Services in the toolbar.
Make sure the Active Directory service checkbox is selected. Select the Active Directory service. Click the Edit button in the lower-left corner of the Directory Utility window. Click the disclosure triangle next to Show Advanced Options. Exploring the “User Experience” Advanced Options Pane The default pane for Directory Utility’s Advanced Options is the User Experience pane, shown in the figure to the left. The first option, “Create mobile account at login,” is disabled by default. A mobile account caches user credentials locally so they can be used when the computer is not connected to the directory node.
See “Understanding Mobile Accounts” for more details about mobile accounts and synchronized home folders. The “Force local home directory on startup disk” option is enabled by default. If you deselect this option, and an Active Directory user who does not have a network home folder defined logs in, Mac OS X creates a local home folder in /Users/ username for the user when the user logs in (unless a local home folder already exists).
Specifying a Network Home Folder There are two possible ways to specify a network home folder:. If your Active Directory schema has been extended to support Apple objects and attributes, map dsAttrTypeStandard:HomeDirectory to an extended attribute in your user record, and use Workgroup Manager to specify the home folder. Enable the option “Use UNC path from Active Directory to derive network home location” and use Active Directory tools to populate the Home Folder field for an Active Directory user. The Active Directory plug-in maps dsAttrTypeStandard:SMBHomeDirectory to Active Directory’s dsAttrTypeNative:homeDirectory.
You can also specify this option with the -uncpath option of dsconfigad. You must specify which file-sharing protocol to use: SMB or AFP (Apple Filing Protocol). SMB is the default setting, so it is easy to use Windows file services to host home folders for Active Directory users who log in to a Mac OS X computer. New in Mac OS X v10.5 is full support for SMB packet signing, a security feature designed to prevent man-in-the-middle attacks, which is required by default on Windows Server 2003 SP1 and later.
Many Windows Server administrators require client computers to use this option, which makes it impossible for computers using earlier versions of Mac OS X to access their SMB share points without installing third-party SMB client software. AFP offers some advantages over SMB as a file service protocol for Mac OS X client computers: It is faster, native to Mac OS X, supports Time Machine and network Spotlight searching, has better auto-reconnect, and handles a wider range of file names in a mixed environment. Unfortunately, Windows servers do not offer AFP by default.
Although Windows Server 2000 and Windows Server 2003 can offer AFP via Services for Macintosh (SFM), the SFM version of AFP is not current. For example, SFM supports only 31 characters in a file name, which causes a problem when Mac OS X uses a long file name, such as /Library/Preferences/ByHost/com.apple.iCal.helper.0017f3e00523.plist.
SFM is not recommended for Mac OS X network home folders. If you must use your Windows server for network home directories, consider running a third-party AFP file service, such as GroupLogic’s ExtremeZ-IP, on your Windows server. You can use a Mac OS X Server to host network home folders for Active Directory users, whether they log in to Mac OS X computers or Windows computers. You can use Mac OS X Server’s AFP service for users who log in to Mac OS X computers, and Mac OS X Server’s SMB service for users who log in to Windows computers.
Active Directory Integration For Mac Mac
Discourage users from simultaneously logging in as the same user simultaneously on Mac OS X and Windows computers, because if they edit the same file over two different protocols simultaneously, this could corrupt the file. For more information about offering file services from a Mac OS X Server, see Chapter 10 of Mac OS X Advanced System Administration v10.5. Logging In with a Windows Home Folder If you use Active Directory tools to define a network home folder ( dsAttrTypeNative:SMBHome) for the user, as shown in the figure to the left, Mac OS X mounts the network volume that contains that Active Directory home folder. Unless you specify otherwise, by default the Active Directory plug-in creates a local home folder on the startup disk, so Mac OS X mounts the Windows home folder but does not use it as the user’s home folder. The network folder appears in the Dock, but the volume does not appear on the user’s desktop by default. The default preference for the Finder in Mac OS X v10.5 is to not display mounted network volumes on the desktop.
To change this in the Finder, select Finder Preferences and select the checkbox for “Connected servers.” The next figure illustrates what the standard desktop looks like for an Active Directory user who has an Active Directory home folder defined. The user opened Finder preferences and enabled “Connected servers” so that the Windows share point appears on the desktop. Note also that the user’s home folder is located on the startup disk, which is the default setting for the Active Directory plug-in. Some things to note:. The home folder is not on the startup disk. This user did not enable the option to show connected volumes on the desktop, so the volume containing the network home folder does not appear on the desktop.
The user launched the Kerberos application to confirm that Mac OS X obtained a TGT, then the user closed the main window of the Kerberos application. The icon for the Kerberos application displays how much time is remaining (in hours and minutes) in the validity of the TGT. The usual TGT lifetime is 10 hours; after that time, the user can reauthenticate to renew the TGT. The question mark in the user’s Dock represents the user’s Documents folder, which has not yet been created. If the network home folder was hosted on a Mac OS X Server file service, Mac OS X Server would create the set of standard folders. Changing User and Group Mappings By default, the Active Directory plug-in generates a dsAttrTypeStandard:UniqueID for an Active Directory user record based on that user’s GUID attribute. The calculated UniqueID is unique across the domain, yet consistent across every Mac OS X computer in the domain.
Likewise, the Active Directory plug-in generates a unique integer for each Active Directory group record as well. If you have extended your Active Directory schema, you can use the Mappings pane to access the appropriate attributes from the Active Directory user and group records.
Be forewarned that if you change the mappings, users may lose access to files that they previously owned or could access. The Mappings pane, shown below, allows you to change the mappings for the following:. UID— dsAttrTypeStandard:UniqueID. User GID— dsAttrTypeStandard:PrimaryGroupID.
Group GID— dsAttrTypeStandard:PrimaryGroupID. If the Active Directory schema were extended with Microsoft’s Services for UNIX, the following would hold:. Map UID to msSFU-30-Uid-Number. Map both user GID and group GID to msSFU-30-Gid-Number If the Active Directory schema were extended with RFC2307 or Apple object classes and attributes:. Map UID to uidNumber. Map both user GID and group GID to gidNumber Exploring the “Administrative” Advanced Options Pane The “Prefer this domain server” option shown in the figure below specifies a domain controller to use for the initial bind.
Use the “Allow administration by” option to enable any user of the Active Directory groups that you specify to be in the group of local administrators for this Mac OS X computer. This is useful if you create an Active Directory group and populate it with users who should have the authority to administer the Mac OS X computers in your organization. When you add Active Directory to your search path, Directory Utility adds the node Active Directory/All Domains to your search path by default.
If you want to restrict the authentication search path to use specific domains only in your forest, follow these steps:. Deselect the option “Allow authentication from any domain in the forest,” then click OK to dismiss the Active Directory services pane. Click Search Policy in the toolbar of Directory Utility, and then click the Authentication tab. Select Active Directory/All Domains, click the Remove ( -) button in the lower-left corner of the Directory Utility window, and then click OK at the confirmation dialog.
Click the Add ( +) button in the lower-left corner of the Directory Utility window. Directory Utility displays a list of the domains in your forest. Select the domains that you want to enable in your authentication search path and click Add, as shown in this figure. Click Apply to activate the change. Creating the Computer Account in a Custom Location Unless you specify otherwise, the Active Directory plug-in creates computer objects in CN=Computers with the domain that you specified to join. Depending on the configuration of your Domain Controller, this may not be correct. For example, some administrators have a special container (CN) for all Mac OS X computers, while others use organizational units (OU).
Follow the steps listed below to tell the Active Directory plug-in to add the computer to the container CN=MacComputers,DC=pretendco,DC=com. Rather than binding from the default pane in Directory Utility, you will bind from within the Active Directory services pane, which offers different binding options. Open Directory Utility.
If necessary, click the lock in the lower-left corner and provide credentials for a local administrator. If necessary, click the Show Advanced Settings button in the lower-right corner of the Directory Utility window. If your Mac OS X computer is already bound to Active Directory, you must first unbind. See “Unbinding from Active Directory” for instructions. Click Services in the toolbar.
Make sure the Active Directory service checkbox is selected. Select the Active Directory service. Click the Edit button in the lower-left corner of the Directory Utility window. If you are not already bound to Active Directory, Directory Utility displays the dialog shown in the figure below.
If you are already bound, you must first unbind in order to change the location of your computer account. Click OK to start the bind process, and then click OK to dismiss the Active Directory services pane. Quit Directory Utility.
Binding to Active Directory with dsconfigad The dsconfigad command is particularly useful for scripting the process of binding to Active Directory, and it offers a way to bind with custom settings in one step. This command has drawbacks, however: It does not enable the plug-in, nor does it add the Active Directory node to the search paths.
You must also use the defaults and dscl commands to accomplish those tasks. More Info For more options, see the man page for dsconfigad. Using Configuration Options Available Only with dsconfigad dsconfigad offers much of the same functionality that Directory Utility offers: You can bind, unbind, set configuration options, and show the status of a bind. In addition, dsconfigad offers some functionality that Directory Utility does not offer, such as the following:.packetsign —This supports packet signing options for both SMB and LDAP.
SMB signing is required by default on Windows Server 2003 SP1 and later. This caused much frustration with earlier versions of Mac OS X.
The default is to allow packet signing, a new feature in Mac OS X v10.5.packetencrypt —This supports packet encryption options for both SMB and LDAP. The default is to allow packet encryption, which is a new feature in Mac OS X v10.5.namespace —The forest option enables a user to log in even if there is another user account with an identical user name in the forest. Be forewarned that if you specify forest, the Active Directory plug-in calculates each Active Directory user’s local home folder as /Users/DOMAIN username instead of /Users/username. Toggling the namespace setting after Active Directory users have already logged in can cause confusion as Active Directory users perceive the contents of their home folder to be missing. The default is domain.passinterval —This specifies how often Mac OS X changes the Active Directory computer object password, measured in days. It is common for Active Directory administrators to use Active Directory tools to look for computers that have not recently changed their passwords.
The default is for Mac OS X to change its computer object password every 14 days. Providing Managed Preferences to Active Directory Users Using Active Directory Group Policy Objects is the traditional method for managing users, groups, and computers, but Mac OS X is not compatible with Group Policy Objects. If you want to apply Managed Preferences to Mac OS X users, you could do any of the following:. Augment Active Directory with an Open Directory server, and then make Active Directory users members of Open Directory groups to which you apply Managed Preferences.
See “Using Workgroup Manager to Provide Managed Preferences in the Magic Triangle Configuration,” in Chapter 8, for instructions. Use third-party software such as Thursby ADmitMac, Centrify DirectControl, or other similar user management utilities. Extend your Active Directory schema to handle Apple-specific object classes and attributes, and then use Workgroup Manager to manage preferences for objects in the Active Directory domain.
See Appendix B.