Parallels Desktop
Parallels Desktop 7 for Mac Run Windows applications without switching between Windows and Mac OS X! Best integration of Mac and Windows. Windows apps now work with Lion feaures, including Mission Control, Launch Pad, Resume, and all trackpad gestures. Supports Windows 7 Aero, with peformance even faster than before. Now runs OS X Server in a virtual machine!

"Parallels Desktop 7 beat VMware Fusion 4.0.2 in 74.9% of the general tests we ran, and Parallels was double the speed or more in almost a quarter of the top-level tests."
--MacTech Magazine


MacWindows Special Report:

Integrating Macs and Active Directory:
Tiger and Earlier

For Leopard AD issues, click here
For SnowLeopard AD issues, click here

Last updated June 18, 2010


On this page:

Send us your experiences with Macs and Active Directory.

Additional Resources on Active Directory and Macs

Related info at MacWindows:

Related info elsewhere:

Apple document: Modifiying the Active Directory Schema to Support Mac Systems

Apple video, Best Practicies for Integrating Mac OS X into Active Directory

Apple's page, Integrating Mac OS X and Active Directory

Big Nerd Ranch, Inc. has posted a tutorial called Mac OS/Linux/Windows Single Sign-On. It describers how to use Active Directory to handle logins on Mac OS X, Windows, and Linux. There are three pages, each with directions and screenshots for each of the operating systems.

Michael Bartosh has an article at the O'Reilly Mac Dev Center on Panther and AD. The article includes screen shots and examples of the dsconfigad command-line utility.

Geordie Korper of Group Logic wrote an article called Creating Active Directory Integrated Home Directories describing using the Group Logic ExtremeZ-IP file server. This Group Logic page contains a brief description, with a link to a longer article in a PDF file.

Snow Leopard Server for Dummies, The 432-page book that simplifies the installation, configuration, and management of Apple's new Mac OS X 10.6 Server software. The book describes how to support Mac and Windows clients for file sharing, email, and directory services, and the other of Snow Leopard Server's services, including the new Address Book Server and Podcast Producer. Other topics including incorporating a Mac subnet into a Windows Active Directory domain, managing Mac and Windows clients, and configuring security options.

Active Directory Introduction

Microsoft calls its Active Directory technology "an essential component of the Windows 2000 architecture." It provides a number of services for large networks, including the authentication and the ability to have a home directory on the Windows server.

There are currently three basic strategies to integrate Macs:

  1. Configure using Apple technology
  2. Thursby Software's ADmitMac
  3. Centrify DirectControl

Using Apple Technology

On February 28, 2002, Apple released a 42-page PDF manual called Integrating Mac OS X with Active Directory [NOTE: Apple has since removed this article.] It describes how Mac OS X can authenticate on Microsoft servers using Active Directory in various scenarios, and includes screen shots and illustrations. Apple's announcement of the manual included this description:

It is now possible to integrate Mac OS X computers into environments based on Microsoft's Active Directory. This includes maintaining Mac OS X user names and passwords in Active Directory, authenticating Mac OS X users with Active Directory and allowing users to mount their network home directory based upon information stored in Active Directory....

With Mac OS X's open directory services architecture and built-in support for open standards, Mac OS X desktops and servers can now leverage directory services wherever they reside - in a Macintosh NetInfo directory, in a Microsoft Active Directory, or in an enterprise LDAP directory

Apple has also has a 62-page PDF manual called Understanding and Using NetInfo, describing how to set up Mac OS X Server to use the NetInfo network database. (Links to both documents can also be found at Apple's Mac OS X Server page.)

(For information on OS X authentication with NetWare LDAP, see our NetWare special report page.)

The ability of Mac OS X to authenticate using Active Directory centers around using Kerberos or LDAP protocols. Kerberos was included starting with Mac OS X v.10.1. MIT has an interesting FAQ page about it. In answer to the question "how to configure Kerberos on Mac OS X 10.1," it says:

You must copy or create a file called edu.mit.Kerberos in your /Library/Preferences directory. The Kerberos configuration information (equivalent to the krb5.conf on other platforms) should be in the data fork of this file. We strongly recommend you read the Kerberos Preferences documentation for more information.

The Kerberos Preferences documentation also provides information for doing this with Mac OS 9.

AFP548.com has an article (from May 8, 2003) discussing one of several methods of integrating Macs with Microsoft's Active Directory.

Shukwit.com has information and forums about integrating Macs with Active Directory.

ADmitMac Version History

Thursby releases Leopard-ready ADmitMac 4.0, DAVE 7.0. Thursday, December 27, 2007 -- Thursby Software Systems has released ADmitMac 4.0, a new version of its Mac OS X software for integrating Macs into Active Directory environments. The company also released DAVE 7.0, a new version of the NTLMv2-compatible SMB file/print client/server for Mac OS X. Both new versions add compatibility with Mac OS X Leopard 10.5.

AdMitMac 4 now has an option to automatically disconnect after a specified period of inactivity. It also adds some new options in ADmitMac Deployment Utility, including the ability to turn off ACL support, Dfs drill down, and symbolic link support. You can also now setup volumes to mount at startup, choose the location of sysvol, and modify the update interval of local mcx cache.

The DAVE 7.0 update adds an option to disconnect after a specified interval of inactivity. It fixes problems browsing over a VPN connection, among other improvements.

The updates for ADmitMac and DAVE are free downloads for customers with active support agreements or who have purchased either product after July 31, 2007.

A Leopard-compatible version of ADmitMac for CAC, which supports U.S. Department of Defense Common Access Cards, is still in beta.

If you've used DAVE 7.0 or AdMitMac 4.0 if they avoid the file sharing and Active Directory problems that Leopard is exhibiting (as described on our Leopard Tips and Reports page).

Thursby posts public betas for ADmitMac and DAVE Leopard update. October 29, 2007 -- Thursby Software has released public betas of upcoming versions of ADmitMac and DAVE. The updates are for Leopard compatibility. The company said that the new versions would be "major updates."

ADmitMac is Mac OS X software that integrates Macs into Active Directory with needing a Mac OS X Server or changes to the Windows server registry. DAVE is Mac OS X software that provides an enhanced SMB file/print client/server.

AdmitMac 3.2.2 and DAVE 6.2.2 updates. June 26, 2007 -- Yesterday, Thursby Software releases ADmitMac 3.2.2, an update to the Mac OS X software for integrating Macs into Active Directory networks. Thursby also released DAVE 6.2.2, an update for the SMB file and print sharing software for Mac OS X. (ADmitMac includes DAVE’s functionality.) Thursby also offers a version of ADmitMac that supports the US Department of Defense Common Access Cards.

The new versions boost performance and improve functionality for support of Windows Vista, as well as fix minor bugs. ADmitMac 3.2.2 adds the ability to use certificates instead of passwords to authenticate to a domain. Another new feature is the ability to assign local administrator rights using nested groups.

Both ADmitMac and DAVE upgrades are Intel and PowerPC native.

Thursby releases Intel betas of ADmitMac, DAVE. March 13, 2006 -- Thursby Software has released beta versions of ADmitMac 3.2 and DAVE 6.2 for Intel Macs, available as downloads. The current release versions of both programs, versions 3.1 and 6.1 respectively, do not run on Intel Macs.

ADmitMac 3.1. February 9, 2006 – ADmitMac 3.1 adds these and other improvements:

* Performance increases
* Any folder can be a local home folder location.
* Joining a domain populates the Kerberos keytab with more encryption types.
* The ADmitMac Deployment tool now supports mapping user UID, GID and group GID attributes.

ADmitMac 3. August 23, 2005 -- Thursby Software has released ADmitMac 3.0, a new Tiger-compatible version of the Active Directory integration software for Mac OS X. New features include:

ADmitMac has some features that Tiger doesn't include. For instance, ADmitMac supports NTLMv2 but without SMB signing (Tiger doesn't using signing); Kerberos is encrypted; support for distributed file systems.

ADmitMac also includes an SMB/CIFS file sharing client that does not have some of the problems of the built-Mac OS X client. For instance, the Thursby client does not create the dot-underscore (._) files due to support for NTFS.

Tiger-ready ADmitMac 3 now in beta;
Will support Microsoft NTFS, DFS
July 21, 2005 -- Thursby Software Systems today announced that ADmitMac 3.0 is currently in beta testing and will be released in a few weeks. ADmitMac is software for Mac OS X that integrates a Mac into a Microsoft Directory network.

Thursby said that Apple's release of Mac OS X 10.4.2 update fixes the bugs in the 10.4.0 release that had rendered incompatible.

The new version of ADmitMac adds new features, some of which are not included in Tiger, according to the company. The new features include:

Thursby releases ADmitMac 2.0. August 17, 2004 -- Thursby Software has released ADmitMac v2.0, Mac software suite that integrates Macs into Microsoft Windows Active Directory without a Mac OS X Server and without schema changes. Thursby claims that a Mac running ADmitMac v2.0 is no more difficult to add to an AD network is "no more difficult than adding PCs."

The new version has over a dozen new features including:

In one application suite, ADmitMac provides all the necessary tools for deployment, configuration and Mac-client management in Windows Active Directory and NT Domain environments with no schema changes.

Thursby releases ADmitMac 2.0 beta. July 22, 2004 -- Thursby Software Systems has released ADmitMac 2.0 beta (prerelease) available to current customers. ADmitMac is Mac software for integrating Macs with Windows Active Directory and NT Domain environments. Some of the new feature:

A new deployment application for building an ADmitMac install package with custom configuration scripts.

ADmitMac 1.1 adds security enhancements, Panther and MS DFS support. October 27, 2003 -- Thursby is now shipping ADmitMac v1.1, and update to its Mac software that integrates Macs with Microsoft Active Directory and Windows NT domains. The new version also includes support for Panther and support for Microsoft's Distributed File System (Dfs). Thursby mentioned this in its press release:

ADmitMac v1.1 is the only Mac product that provides full support for NTLMv2 in addition to its use of Kerberos and encrypted LDAP authentication. These enhancements allow the new release of ADmitMac to be used with Windows Server 2003 running at full security levels.

Other features unique to ADmitMac include:

and the requirement of "Kerberized" mutual authentication to ensure that the server isn't being spoofed.

ADmitMac 1.0 ships May 15, 2003, Thursby Software Systems shipped ADmitMac 1.0, a software solution that enables Mac OS X to participate in Microsoft networks with Active Directory.

ADmitMac 1.0 Announced April 10, 2003 -- Today, Thursby Software Systems announced ADmitMac (formerly know as Goliath, software for Mac OS X 10.2.x that allows Macs to participate in Microsoft networks, integrating with Active Directory and older domain services. Unlike Apple solution for Active directory solution, no Active Directory schema changes are required. ADmitMac is expected to ship in May, and is currently undergoing beta testing.

ADmitMac allows Mac users to be authenticated by the directory server, and enables users' home directories to be kept on Microsoft servers and managed from the directory. This enables users to log in from a Mac or PC using the same account and password and have full access to their files and desktop settings. The system administrator does not have to do anything extra to support the Mac OS X clients, according to Thursby.

ADmitMac and AD integration in Panther

Thursby refutes Apple claims of AD integration in Panther. November 25, 2003 -- Thursby Software Systems has posted a paper comparing its ADmitMac software for Mac OS X to Panther's built-in active directory and SMB file sharing capabilities. The paper disputes claims by Apple (and reported here) that Panther's home directory can by an SMB volume. Thursby says:

Although Apple claims that they support "SMB Home Directories," it is also apparent that they do not understand the true use of this feature by most of their customers. Panther merely mounts the Home Directory at log on, while ADmitMac allows you to actually use it for your home directory. With Panther, all of your Mac home directory files reside on the physical Mac that you log in to. With ADmitMac, you can specify that your SMB Home Directory also functions as your Mac home directory allowing you to log in to any Mac or PC on the network and have complete access to all of your files. This powerful feature of Active Directory is missing from Panther.

Thursby also claims that Panther lowers the security level of a Windows Server 2003 network:

...it is interesting to note that Panther actually requires you to downgrade the security levels of Windows Server 2003 in order to use a Macintosh with it. Microsoft has stated that its earlier protocols were "vulnerable to widely published attacks for obtaining user passwords." ADmitMac v1.1 provides full support for NTLMv2 in addition to its use of Kerberos and encrypted LDAP authentication. These enhancements allow ADmitMac to join Microsoft networks with Windows Server 2003 running at full security levels.

Thursby also takes Apple to task for SMB browsing problems with Panther that we and others have reported:

Apple's [SMB] browser still doesn't work in most real world corporate and educational environments. This is a clear indication of Apple's lack of sufficient development labs and customer beta test environments.

Within the first week after Panther's release, internet news groups were filled with customers complaining that they could no longer see most of their networks. Unless you can see the remote computer, it is very hard to even try to share files and printers with it. Several internet web sites and publications simply quoted Apple's announcements of all of their new features, and then started to question many of the claims after their readers started reporting the facts back to them.


Reader Reports

Integrating with Apple Technology

December 28, 2001
Jason Elliott describes MIT's role with Kerberos and sent a link for LDAP information:

Kerberos: MIT has been collaborating with Apple for the authenticator, and they have posted it on an MIT Kerberos for Macintosh site. The authenticator works on an OS 9 box. I haven't had time to try it on an OS X box.

LDAP: There are folks developing a version of lookupd to work properly with LDAP v2 and v3. Check out PADL Software's news page. These are people contributing code to Apple development.

Windows 2000 Advanced Server AD: You would install MS Services for Unix to work with exporting Active Directory information via LDAP to lookupd.

OS X Server: Adjust settings in the Directory Services application if necessary for LDAP's mapping user data.

December 28, 2001
Michael Perbix has been partially successful with LDAP:

I have successfully (with the help of an Apple SE) used the Active Directory controller at our site to also act as an LDAP server. At the moment this is a one way deal, and I have not been able to use it for OS X authentication itself, but I HAVE used it for importing user and group info into Macintosh Manager. It takes a bit of editing on OS X LDAP authentication services, and knowing the proper schema items needed from the AD server, however it does work.

January 10, 2002
Kyle Crawford

I've had success with logging into our Windows Domain using Kerberos as well.

Here are a few gotchas:

1.) If you are getting 'encryption type not supported' messages, try changing your password from a Windows machine. Windows NT 4 user accounts that have been upgraded to Windows 2000 will not work until their passwords have been changed. The password change triggers Windows 2000 to generate a DES encrypted version of their password--which is required for MIT standard Kerberos.

2.) The Mac OS X screen saver does NOT use the Kerberos password, so one must use the local account password for this to work--which makes the domain authentication somewhat useless since you already have a local account password.

3.) Unlike Windows, Mac OS X is not able to cache a profile for the user, so when off the network, a user will need to enter the local account password--again making domain authentication somewhat useless.

4.) The Kerberos Login Authenticator uses the short name, but Mac OS X defaults to the long name in the login panel. To avoid confusion, it might be best to make both your long and short names match each other in addition to matching your domain username.

I'm still doing some experimenting. I'm still not sure how Kerberos relates to the Directory server hierarchy. For example, can one use Kerberos to login and still get your home directory info from an LDAP server? Are they separate entities?

This is exciting stuff. I'm impressed. I hope that other Mac Managers will encourage Apple to keep up the good work in this area and provide some documentation for Kerberos and LDAP.

Our IT department has been willing to add entries to Active Directory to help out.

Next project: using LDAP to set home directories and browse for servers and LPR print servers. If anyone has had success with that, please share.

You can share by e-mailing MacWindows.

Active Directory problems in Jaguar

(NOTE: We have more on Active Directory integration using Mac OS X Server on our Pre-Jaguar Mac OS X Reports page.

August 30, 2002
Tony Chow says that OS X 10.2 is unable to resolve DNS names in the .local namespace.

I'd like to report a severe problem that we encountered when trying to integrate OS X version 10.2 with our Active Directory network.

Our organization's Active Directory infrastructure relies on a private DNS domain with a .local suffix (i.e. mydomain.local). After we upgraded our Macs to OS X 10.2, however, we are no longer able to resolve any host names within the AD domain. I'm pretty sure this problem has to do with OS X 10.2's new Rendezvous/ZeroConf feature, which uses a name resolution scheme that hard-codes a .local suffix to a device name. Apple engineers, apparently, reserved this namespace for Rendezvous only and precluded its use for normal DNS use. If this is indeed the case, Apple has made an inexcusable mistake, for, AFAIK, DNS names with the .local suffix are perfectly legal and are used from time to time on networks that need private namespaces that do not collide with public domains. It is simply unreasonable to assume that the .local namespace can be usurped for a single purpose without harmful ramifications.

For the time being, we are forced to fall back on using naked IP addresses when sharing files with the OS X clients.

August 30, 2002
Henrik Boes

I'm wondering if other folks are struggling with getting Active Directory integration to work. We have a simple single domain setup in our agency, with two Win2K DCs. While I can browse and connect to them via SMB just fine, I am not able to eliminate re-authenticating when accessing the share points, even after configuring the LDAPv2 and LDAPv3 settings in the Directory Access utility (as best as I know how, given that detailed Mac Help on the matter is MIA).

A have a few questions:

- Is the whole concept of AD integration the same in Jag as on Windows, i.e., one log-on regulating access to all resources within the domain?

- Do you need to configure both LDAPv2 and LDAPv3 settings in Jaguar to talk to AD (AD supports both versions; are both necessary on the Jag side for full functionality or is it either/or?)

- Does the Mac OS X logon change in any way? In other words, do I need to include the domain name when putting in my username?

September 26, 2002
Steve Talley reports reports problems with Active Directory he believes are cause by Rendezvous, Apple's implementation of an auto-discovery service:

In regards to the two postings on your OS X 10.2 compatibility reports on problems with Active Directory integration, I too have experienced problems.

Where I work, we have a Windows 2000 Active Directory domain set up in the .local namespace. As it has been pointed out, Rendezvous is adding a .local name extension to everything. The result is that I cannot access any other computers on my network from my Mac running 10.2 by their DNS names. Accessing them via their IP address works, but who wants to do that? The whole point of a DNS system is to eliminate having to enter in IP addresses.

Pings in the format of "ping servername" or "ping servername.mydomain.local" both fail. On any other machine not running 10.2 (Mac OS X or PC), both of those commands work fine.

In the Sharing tab, I've tried filling in nothing in the Rendezvous tab (it comes back on a restart), filling in just the computername of the 10.2 box, and filling in "computername.mydomain". None of those resolve the problem.

Is there a way to disable Rendezvous altogether? It's a great idea -- but at this point it's causing problems.

I also have been unsuccessful in getting the LDAP settings to work to allow me to authenticate against the Active Directory domain when I log in. I don't know if it's because of the whole .local mess or not since the documentation (what documentation?) on setting LDAP up is rather sparse.

If you've seen these problems,

Rendezvous causing problems with Active Directory in Jaguar?

September 26, 2002
Steve Talley

In regards to the two postings on your OS X 10.2 compatibility reports on problems with Active Directory integration, I too have experienced problems.

Where I work, we have a Windows 2000 Active Directory domain set up in the .local namespace. As it has been pointed out, Rendezvous is adding a .local name extension to everything. The result is that I cannot access any other computers on my network from my Mac running 10.2 by their DNS names. Accessing them via their IP address works, but who wants to do that? The whole point of a DNS system is to eliminate having to enter in IP addresses.

Pings in the format of "ping servername" or "ping servername.mydomain.local" both fail. On any other machine not running 10.2 (Mac OS X or PC), both of those commands work fine.

In the Sharing tab, I've tried filling in nothing in the Rendezvous tab (it comes back on a restart), filling in just the computername of the 10.2 box, and filling in "computername.mydomain". None of those resolve the problem.

Is there a way to disable Rendezvous altogether? It's a great idea -- but at this point it's causing problems.

I also have been unsuccessful in getting the LDAP settings to work to allow me to authenticate against the Active Directory domain when I log in. I don't know if it's because of the whole .local mess or not since the documentation (what documentation?) on setting LDAP up is rather sparse.

September 27, 2002 -- Jason Prell answered the question of how to disable Rendezvous in Mac OS X 10.2. Open the Directory Access utility (/Applications/Utilities/) and uncheck Rendezvous in the enabled list.

March 24, 2003
Bill O'Connell

As others have noted, Mac OS X 10.2.4 does not resolve any .local host names that are handled by traditional (i.e., non-Rendezvous, non-Zeroconf) DNS. Unfortunately, turning off Rendezvous as described by Jason Prell in the September 27, 2002 Jaguar Reader Report does not resolve the problem. If you open a terminal session and use the tcpdump utility, you can see the Mac sending multicast DNS (i.e. Zeroconf) requests on UDP port 5353 when you try to resolve any name that ends in .local.

Solutions for .local problem

March 26, 2003
Jason Prell updates his September report (above) with some additional information on turning of Rendezvous:

I have noticed that the mDNSResponder (Rendezvous) process is still running after unselecting it in Directory Access. You can avoid having the process running by removing (or moving and backing up) the startup item.

If you want to prevent Rendezvous from running on the system, move /System/Library/StartupItems/mDNSResponder directory to a backup location and restart the system. Just don't muck around with settings that depend on it, like the Rendezvous plug-in in Directory Access after removing the startup item.

March 26, 2003
Larry Paxton sent a solution that used the Terminal application:

I experienced the same problem of OS X Macs not being able to resolve .local addresses on my internal LAN. After scouring the net, I found this fix that worked:
  1. Open the Terminal Application
  2. Type the following (Must have root privilege or sudo account): sudo pico /etc/resolver/local
  3. You will see three lines in the file: nameserver ipaddress, port 5353, timeout 1
  4. On the nameserver line, replace the current IP address with the address of your local DNS server: for example nameserver 10.0.0.1
  5. On the port line, replace 5353 with 53.
  6. Save your changes and quit pico.

You should be able to resolve .local names properly.

Active Directory authentication in Jaguar--how real is it?

October 4, 2002 -- Steven Allred reports that an Apple rep told him that the advertised ability of Mac OS X 10.2 to authenticate to a Windows Active Directory server is not actually in Mac OS X. His report:

I am a Computer Specialist for a large creative entertainment company. We have been working with Apple for a month now on getting Active Directory (AD) authentication to work. There are the facts as I know them for our Sr. Apple Engineer assigned to our company. He has said that the advertisements for AD support (10.2 box, and Apple's website) is ahead for the actual abilities of the product. He has continued to say that he has only found one guy at Apple that is currently working on this, and they get promising that it will be able to demonstrate it to us, but so far nada. Having an Xserve does improve the ability to do AD authentication, but it is still not 100 percent ready.

Currently, it does not work right out of the box (as advertised), as you need plug-ins that are not yet finalized by Apple. It requires you to add and make adjustments to the AD server that haven't yet been thoroughly tested or verified or signed off by Microsoft for any possible security issues. It will be very hard or impossible for us to apply any changes to our AD servers for OS X client to authenticate.

If you know any other information or no anyone who has this working please let me know and I'll share it with Apple.

(As we reported earlier this year, it is possible to integrate Macs using a Mac OS X server on the network. With Mac OS X 10.2, Apple claims you don't need a Mac OS X Server.)

Tips for Jaguar and Active Directory--some say MS Services for Unix helps--others say no.

A number of readers have responded to the October 4 report (directly above) questioning the accuracy of Apple's claim of Active Directory support in Jaguar. Several reader have report varying degrees of success through different methods, including running Services for Unix on the Windows server.

October 7, 2002
William Rundquist was one of the readers reporting success. He agrees that modifications were needed to Active Directory, but got around it by using Services for Unix:

We have managed to get Active Directory authentication working with Jaguar. The secret for us was that we already use Microsoft Services for Unix (we upgraded from version 2 to version 3 after installing Jaguar and were able to authenticate with either version installed) to provide NIS authentication to our other Unix systems (and, in fact we also use Microsoft's Internet Access Server for RADIUS authentication thus giving us a complete single signon setup).

However, Apple's out of the box LDAPv3 configuration did not work. We had to make extensive modifications to the mapped fields to get authentication to work. But since Services for Unix modifies the AD schema and adds a number of "unix required" fields, we were able to use those fields to get Jaguar to authenticate.

One non-obvious issue was the HomeDirectory verses NFSHomeDirectory fields in the LDAPv3 field mapping. It turned out that for non-local (i.e. network authenticated) accounts that the NFSHomeDirectory field RATHER THAN the HomeDirectory field is used.

As a side note, prior to Jaguar we used the NIS client support built in to Lookupd for authentication. This worked very well for us until Jaguar when we could no longer authenticate via NIS. We're hoping that Apple will provide a NIS client in the Directory Manager at some point in time.

Another thing that we have discovered is that the LDAP client is unstable. We had severe problems with ldap connection timeouts causing out Jaguar systems to have to be rebooted on a regular basis. Apple's default timeout values of 120 seconds for both connection and retry timeout are way too long. We discovered that by shortening those timeouts to 1 second each we could get a somewhat more stable situation but it is by no means as stable as we were use to with NIS authentication.

October 7, 2002
Chuck Simciak agrees that adding Services for Unix the the AD server helps:

I've done some work with LDAPv3 Authentication and documented it here.

However, its very incomplete since you don't even have a GUI. In speaking with a few other people I get the impression that some of the changes needed for AD involve modifying the schema. Unfortunately, these changes are GLOBAL so for large organizations you may have to bounce these changes off a committee.

The schema changes needed involve adding GID, UID, Primary Group, and possibly reformatting the homeDirectory entry since entries like "H:\" won't fly with OS X. Adding Unix Services for Windows can accomplish quite a bit of this without having to fiddle with the schema editor but I haven't had time to test this.

How OS X Server make this easier I'm not sure other than the fact setting up one box (a server) to LDAP could be easier than X number of clients.

So, yeah, technically it works but this isn't what I was expecting from Apple.

October 7, 2002
William Paquier

I have the same problem with LDAPv3 (AD) and Jaguar. We have solved some questions at an Apple discussion forum. The problem has been decomposed into three issues:
  1. Authentication (it seems to be okay)
  2. Having a UniqueID (it can be solved by mapping another unique value)
  3. Mounting the home directory (I suppose it can be solve with a NFSHomeDirectory field like "/home/user" and an amd startupitem).

October 7, 2002
Miguel Chan expands on the separation of Authentication from other issues:

I have been able to get OS 10.1 & 10.2 (without OS X servers) to authenticate via Active Directory. The problem lie in the fact that there doesn't seem to be a way to make the authenticated network user an Administrator on the machine. Therefore authenticating is useless since once logged on you don't have a local home, none of your settings are saved, and programs that require a home in order to save preferences bomb out. If there is a way to configure a network user to have Administrator rights on the local machine then we have possibilities.

October 7, 2002
Henrik Boes

Just wanted to follow-up on your AD report today, as well my report from 8/30 .

First, a reaction (assuming that what Mr. Allred says is confirmed to be true): To tout Windows integration and have a nonfunctional AD integration tool is simply ridiculous (to put it mildly). What a great way to get bad press. Wait until someone at wininformant.com or cnet.com gets a hold of this one.

There is definitely more documentation for AD integration in 10.2.1. Looks like the protocol of choice, for example, is LDAPv3. The problem is that none of the truly tricky parts (modifying the "search base", writing changes to the AD server - something that sounds like modifying the AD schema to me, a scary thought as a bad schema mod can take down your whole domain) is explained in any detail at all.

AD integration is not going to be as easy as setting up a scanner or the like, which makes thorough documentation all the more important. And, of course, even more important than that is a functional bit of software.

October 7, 2002
Michael Perbix sent some interesting comparisons to the now discontinued product MacaNTee from Alaran, which Perbix said did offer true Active Directory integration.

We have had our Xserve talk to AD and be able to authenticate and use the user list in Macintosh Manager. I have also been playing around with making the groups work. This has mostly been done by our local SE from Apple. It works. You can login, and use your AD member list for Macintosh Manager, however this is all happening over LDAPv3, not true AD integration as the old macaNTee did.

There are a few problems with not having true AD integration. For one, if you disable an account in AD, the person can still log in on a Mac since the LDAP information does not indicate the account is locked. Also in every persons account the home directory is already specified, a true plug in should be able to take that and parse it to work either in AFP or SMB from the Mac.

Groups are also a very important thing. It needs to automatically take spaced names and replace it with another character like _ since Apache does not like group names with spaces.

I would also wish that the AD would provide windows services with the behind the scenes authentication as windows users have enjoyed all along. Since all our servers are windows based, I would love to turn of authentication on our proxy and be able to use NTLM to pass the users name/password

This type of integration is what is needed to make the Mac an equal citizen in the windows world. That is the reality for a company such as mine that can not reinvest in converting servers and equipment. I was very unhappy when I heard that Alaran stopped production of the MacaNTee product since that was the FIRST and ONLY product on the Mac that started heading in that direction. Dave is a good alternative, however, in a large organization it is not practical and still does not do the basic stuff noted above. If they could wedge Dave into the whole login system instead of being an additional layer, that would be a good start.

October 11, 2002
Michael Bartosh, a Mac OS X consultant, sent some information on integrating Mac OS X with Active Directory.

> One non-obvious issue was the HomeDirectory verses NFSHomeDirectory
> fields in the LDAPv3 field mapping. It turned out that for non-local
> (i.e. network authenticated) accounts that the NFSHomeDirectory field
> RATHER THAN the HomeDirectory field is used.

This isn't really correct. The two are used in concert, and for a good cross-platform user experience you have to do some work:

a) Win clients expect unc paths in homeDirectory
b) For AFP or SMB home directories, Macs need a plist with a url (this is the attribute I created in AD)
c) Macs will also need a path to their home directory (created based on the above plist and at least 1 automount object).

This guy probably didn't map a numerical user ID. Hence the textual login.

Also:

> How OS X Server make this easier I'm not sure other than the fact
> setting up one box (a server) to LDAP could be easier than X number of clients.

There seems to be an impression that Mac OS X Server acts as some sort of LDAP proxy. This is not the case. Mac OS X clients talk directly to the AD for authentication and authorization data. Having them look simultaneously at OpenDirectory is simply an efficient way of sharing data that is not applicable to non-Mac clients.

> The problem lie in the fact that there doesn't seem to be a way to
> make the authenticated network user an Administrator on the machine

Just add the network user name (usually sAMAccount) to the local admin group.

> herefore authenticating is useless since once logged on you don't have
> a local home, none of your settings are saved, and programs that
> require a home in order to save preferences bomb out. If there is a
> way to configure a network user to have Administrator rights on the
> local machine then we have possibilities.

This has nothing to do with the user's status as an administrator, however.

He probably hasn't mapped the plist / path / automount triad necessary for home directories.

Apple responds: Active Directory support in Jaguar is real and works.

October 11, 2002 -- We spoke with Eric Zelenka, Apple product line manager for server software, about our recent series of reports on Active Directory integration in Jaguar. Zelenka says that Active Directory support is included in Mac OS X from v10.1 and later, and that it does work and doesn't require a Mac OS X Server. With Mac OS X 10.1, support was only for LDAPv2 authentication; Jaguar supports both LDAPv2 and LDAPv3.

We asked Zelenka why so many of our readers--including network admins at large companies--were reporting problems. He said "There are always growing pains as people try new technologies."

As to why changes are needed to be made to the Windows Active Directory Server, Zelenka said that you need to make changes when you add any non-Windows client. "Anytime you add directory properties, you have to add fields." He agreed with several of our reader reports that installing Services for Unix makes these changes, but noted that Services for Unix is not required.

Zelenka also pointed us to some further help. A University of Colorado QuickTime movie called "How do I setup Directory Services for Mac OS X was presented at the last Worldwide Developers Conference. The movie isn't specific to Active Directory, but does present a tour through Mac OS X's tools. Zelenka also mentioned that the Mac OS X Server Admin Guide has information on configuring directory access, even without the use of OS X Server.

Zelenka also refuted yesterday's report of a plugin in the works for Active Directory. He said that it is Mac OS X that has the plugins. Mac OS X 10.1 had a plug-in for LDAPv2, and that Jaguar has a plugin for LDAPv2 and LDAPv3.

More reader suggestions on Active Directory and Jaguar

October 15, 2002
Jason Prell advises against installing Services for Unix on a Windows server in order to add active directory support for Mac OS X:

I read some stuff that was posted on your site about the Active Directory and OS X Client integration. The Microsoft Services for UNIX 3.0 is not a good idea, because it does not have the required attributes for linking to the attributes with OS X.

I have been doing 2 months of research and investigating what objects need to be added to the Active Directory schema and the registered Object Identifiers. There are registered OIDs by Novell. This may seem confusing, but Novell registered them and note the information on their guide for integrating OS X with their eDirectory product. The reason why OIDs were not registered by Apple or someone else is because they are already created, so you wouldn't want to create another unique ID if it already exists.

The objects and attributes outlined on this University of Iowa web page is the proposed implementation that I documented which allows support for a network Home Directory that can be shared with a Windows XP Home Directory for cross platform file access. Using folder redirection with Windows XP, you can have the Documents folder in OS X and the My Documents folder in Windows XP contain the same data on any computer on both platforms creating a single file store location for students, and other users.

I would avoid MS Services for UNIX at all costs since it is costly and adds a lot of unused classes and attributes to your Active Directory schema that would not really ever be used.

October 15, 2002
William Paquier sent us a link to a page by Michael Bartosh that details some configuration issues surrounding Active Directory issues. (Bartosh previously sent us some helpful information, which we published on October 11, above.)

October 15, 2002
Dedrick Allen

I have been following the Active Directory discussions on the site and I think people are a little confused as to what is required and how it works. I am going to try to explain, as we have it working several different ways. Although it does require a couple of modifications to the AD schema, they are small and Apple documents it pretty well if you understand directory services.

We have a Mac OS X Server v10.1 running and it is authenticating via LDAP to our Windows 2000 Domain Controller. However, the server is only in place to allow Mac OS 8-9 workstations using Macintosh Manager to authenticate. This allows users with accounts on the Windows 2k domain to go to a Mac and log in. The X Server is running the Macintosh Manager service and performs all the required authentication for the Mac OS 8-9 client workstations running the Macintosh Manager client. We made a couple of changes to the AD schema to allow HomeDirectory and UniqueID. We did not use Windows 2k's AD homeDirectory attribute. We created another one named afp_homeDirectory and populate it as well as the UniqueID attribute at the time we create a user. Although we wrote a custom application to do this, you can do it with Windows scripts easily as well. We mapped the afp_homeDirectory with a properly formatted path that OS X can understand and that path points to a Mac Volume of our users My Documents folder on the Windows 2k domain servers. This allows users to log into a Windows professional workstation and access their My Documents folder and then be able to log into a Mac OS 8-X workstation and have access to the same documents. This works on OS X client as well when the directory services are configured like the OS X Servers are. For the OS X client workstations they do not talk with the OS X Server, they can talk directly to the Windows domain controller without a X Server. If you are an all OS X workstation house you do NOT need an X Server to authenticate with Windows 2k AD. Just configure the directory services on the X workstation and make the necessary changes to the AD schema. If you have Mac OS 8-9 clients then you need an OS X Server with Macintosh Manager services running on it to allow those clients to authenticate via the Windows 2000 domain.

I hope I explained this well and in a clear form. I hope this helps clear up some of the confusion.

November 18, 2002
Jason Elliott started a thread at SlashDot that contains advice on configuring Mac OS X for Active Directory:

There's a SlashDot thread for "'Seamless' integration of Mac OS X w/ Active Directory" on now. There are some good posts on bringing people down to earth about what you need to do to get this working.

And after some research, it turns out MS Services for Unix will do most of the AD schema modification for you. This, the PDF from Apple and some tweaking may be all one needs.

We've reported that MS Services for Unix will do this before. Apple told us (above) that it wasn't necessary, while other readers advised against it.

November 18, 2002
A reader, who wishes to remain anonymous, repeats the claim of another user, that Apple is working on an Active Directory plugin for Mac OS X 10.2:

I have seen with my own eyes the Active Directory Services plug-in for Jaguar, the existence of which Apple's Eric Zelenka previously denied on your web site.

The plug-in is installed by running a standard installation program. It then makes an additional option available in the Directory Access utility which allows one to configure Mac OS X to specify an Active Directory domain and AD admin name and password to use when authenticating against an AD server. It offers the ability to auto-calculate a UID based on an attribute already stored in AD without requiring any modifications to the AD schema, and can locate and mount a user's home directory from the Windows server, again apparently without requiring modifications to the AD schema.

This is in contrast to the existing LDAP v2 and v3 plug-ins which, if one wishes to use to authenticate against AD, require changes to the AD schema.

Wonder why this plug-in is keeping such a low profile?

Integrating with Thursby's ADmitMac 1.0

May 22, 2003
Brian Frobisher

I downloaded the demo copy of this software. I am using it with an NT domain. After fiddling around with it I did get it to work. It's pretty interesting. Anyone in the DOMAIN can log onto the Macintosh and their Home directory is there, but not mounted on the desktop. It is in a folder called Domain on the hard drive.

I emailed Thursby and told them it would be much cooler if the home directory could mount on the desktop. Also, files in the home directory "MOVE" when you drag them to the desktop, not COPY, which is kind of strange.

May 28, 2003
Chuck Simciak

The comments made by Brian Frobisher are correct and make perfect sense.

1. ADmitMac mounts the home directory in the same fashion as an OS X server. It uses a NFS/Unix style of mounting in which the network based home directory appears to be a part of your local file system. If you click the Home button your home directory appears in the Finder window even though its on the network. If you really have to have the home directory appear on your desktop make an alias to your home directory and put it on your desktop.

2. A network based home directory isn't located in a folder called Domain on your hard drive. Though such a folder is created it simply contains a link to the network based home directory. I don't know why Thursby did this but that's how it works.

3. Moving files from your home directory to the desktop SHOULD move instead of copy. This is because the Desktop folder which stores items found on the desktop is located in the home directory. "Copying" files from the home directory to the desktop is actually a move from the home directory to the Desktop folder located in the home directory. Now, if you tried moving files from the hard drive (anything outside of the home directory) to your desktop that would be a copy and not a move.

May 28, 2003
Scott Adamson likes ADmitMac, but his elementary school can't afford it:

I would like to comment on some things I have seen with the demo.

I was able to connect easily and completely to a Windows 2000 Active Directory server (the files on the desktop of the PC appeared on the desktop of the Mac). So far, this application/plugin seem to be the most complete and easiest way to integrate a Mac into an existing active directory infrastructure.

That being said, the cost - even for education (I'm a Mac admin at a K-12 school in NYC) is prohibitive. Costs somewhere in the $12,000 price range for 250 clients! I could spend 3-4 months nonstop on this problem and about break even.

It is disappointing that this currently is the best and easiest solution and Apple has not created a similar way for the 5 percent of the Macs to connect to the existing AD systems and it truly is no where near as easy as it sounds to integrate these two systems.

May 28, 2003
Jay Christianson also complained about education pricing:

Thursby did alter their pricing for ADmitMac, but plenty of the educational users who were in their beta list all made the same comment. Still too expensive. I think most of them decided they'd have to forgo this prebuilt solution.

It's too bad. Many of us wrote in to Thursby about it. I personally still believe that they are cutting out what could be potentially their largest market for the product. Integration with Active Directory is only going to be an issue with those shops that run mixed Windows/Mac environments; and it's really only an issue in those shops that have security issues or rely heavily on Windows-based file storage. I think the list of non-educational users is much shorter than that of educational sites.

May 28, 2003
Michael Perbix explains a few things:

The home folders are created either on the network volume that is defined in your Windows account, or locally on the HD. The mount point is /domain/users as opposed to users. The home directory is accessible by clicking on HOME just as it is with a regular user.

The ability to browse your Windows workgroups or the AD is rather nice, and the SMB/CIFS client is rather speedy. It does work better than the Apple SMB client and is more compatible with NTFS/SFM/OS9 users. As it does not create the dual files per file you copy to the server. It stores its resource information in the NTFS file stream just like NTFS and SFM.

The print client allows you to browse your print shares as well and provide security credentials so you can use native print sharing and lock down printers using Windows security information.

The client also allows some coexistence with Workgroup Manager so that you can have your local client authenticate to the domain and use workgroup manager control security settings for group/machine security.

The client also cache's login info, so mobile users can log in once to the network then detach and continue using the computer without needing to be on the network. However (of course) home directories need to be local instead of network based in that instance.

The client should work with user templates so when a new domain user logs in the default template should be used to create that users account.

Overall I think it is a great 1.0 product and will only get better as more people use it and more feedback gets to Thursby....

May 28, 2003
Nick Pitman wished ADmitMac could work with ExtremeZ-IP:

I have looked at ADmitMac Demo and agree that it looks OK and could potentially be very useful in a environment with Windows servers. Problem for me is it is not designed to work with AFP over IP solutions like ExtremeZ-IP. If it did work with AFP shares it would look like a good way forward from the sadly defunct MacaNTee as a method of authenticating Macs on a Windows domain with auto server mounting etc. This solution would appear to allow you to save all user defined settings with your home directory on a central server so you can connect to any networked Mac and pick up your preferences - useful with email profiles Internet favourites, etc. I really wish I could find a solution a bit like this that would work with ExtremeZ-IP, when we eventually move from Mac OS 9 to Mac OS X.

May 28, 2003
Derek Smith talks about configuration:

A few preliminary notes on ADmitMac (Tested with eMac 700 MHz 500 MB RAM OS X 10.2.6):

The install was painless and involved few steps. ADmitMac successfully created the computer account on the AD server all by itself, and creating a computer account in the ADS ahead of time worked as well. Thursby's admonition about using the same DNS for the client machine as well as the ADS is warranted and should be heeded.

The user's Home Folder appears in a 'Domains' folder in the HD, which is problematical, but which could be mitigated by an AppleScript of some sort (less desirable) or by a change in the way Thursby does things (more desirable....)

In addition, through the Go -> Connect to server.... menu the following volumes can be mounted when accessing the AD server through the list of computers visible in the domain. This is very insecure but may reflect misconfiguration on the Win2K/AD server, which I do not manage. I have not tried trashing any of the files found in these Volumes for fear of crashing the AD server. ;-)

Available & mountable Volumes:

mspclnt
netlogon
sysvol
vphome
vplogon

Upon first logon, a user's home folder is populated with the default user's OS X folders (Desktop, Library, Music, Movies, etc).

Because school OS X Admins are a bit fussy about security and locking down machines from tampering, I'd like to be able to mount the home folder alone, but NOT store user prefs for the machine in the user's folder. Instead, the user's prefs (desktop, library, music, etc) should come from a local, locked folder. Alternatively, If I could modify the default user's OS X folder structure to reflect the preference changes I need, it would work better.

I'm going to compile a wish list for Thursby along these lines. Although their software saves me many man-days of trying to figure out LDAP & etc, their implementation leaves a fair amount to be desired.

January 5, 2004
Adrian Newby prefers using Thursby's ADmitMac over Panther's built-in Active Directory integration features:

I have no affiliation whatsoever with Thursby so don't take the following as a shameless marketing promotion. I'm just someone trying to leverage Mac technology in a Windows world.

In desperation, I decided to look at ADmitMac after their Nov 25 post and after many fruitless hours trying to get AD integrated with Panther. Short answer is, one download and install later, all my AD integration issues were gone at a single stroke. No tricky configuration &endash; nothing. I now have complete authentication, browsing and volume mounting, just as their paper described.

I would recommend the product to anyone.

If I had to do it over again, I would have paid the $199 on day 1 and avoided wasting the many hours I spent wrestling with Panther in this area.

January 5, 2004
Jose Medeiros has also found ADmit Mac to work:

Active Directory is based on LDAPv3.0 with of course Microsoft extensions. LDAP is on by default and the port it uses is 389 on Windows 2000 server and 2003 providing that Active Directory is installed correctly.

However, I have Mac OS 10.2.8 and I could not authenticate to Windows Server 2003, I could authenticate to Windows 2000 Server running Active Directory with Service Pack 4 installed, but I had to enable LM /NTLM Authentication in the security policy.

I also download Admit Mac 1.1, I installed it, and it allowed me to authenticate to 2003 AD without any problems. I will also check into this further as I am curious as to why this is not working.

I have not tested this in Panther.

Reader has ADmitMac Configuration problem

May 28, 2003
Chris

Have tried setting up with Win 2K domain but have had no success. I don't seem to be able to join the domain and get "Domain controller for dpn.local could not be found". I did get it to join if I told it to join an NT domain. This also appeared to work as users were able to log on but it didn't allow any access to network resources so hard to know if it did work. I'm sure it's some kind of WINS vs DNS problem, i.e. it picks up on the WINS records but not the DNS. I tried removing the WINS server as it's not really used on the network but this hasn't helped.

Suggestion from Thursby

May 29, 2003
Carl Ketterling

As for Chris, the .local top-level domain may be confused in DNS with .local in Rendezvous and may be interpreted incorrectly. To avoid this situation, do not test with .local as the top-level of your domain name. Here's an Apple web page that discusses this in more detail.

Sincerely
Carl Ketterling
Thursby Software Systems, Inc.

SMB folders look empty with Active Directory

June 12, 2003 -- When Michael Larsen switched to Active Diretory, server folders accessed by SMB on Macs look empty. This sounds similar to reports of files becoming invisible when file names are changed, though the circumstances are different. Larsen says:

I'm probably missing something very basic here, but as our organization has moved to Active Directory and Win2K servers, it appears that connecting with SMB in OS X has gotten more and more problematic.

When connecting to various servers, that were not a problem before, I get access to all of the directories (folders) but they all show as empty - no files. It doesn't seem to matter what format for SMB that I use -

smb://servername/share or smb://domain;servername/share or

smb://username@servername/share, etc. the results are the same. Plus, no matter how far down I go in a path to mount a share, only the top level share mounts; ie. smb://Server/graphicshare/folder/subfolder will only mount graphicshare.

I have also been applying Apple's updates as they occur, perhaps mistakenly thinking they are keeping pace with the changes in Windows networking. I'm running 10.2.6 on the Macs, currently. It is beginning to appear that a third party solution, such as DAVE or ADmitMac may provide a more compatible approach.

If you've seen this problem

Problems and solutions with Panther AD integration.

Panther Active Directory integration -- don't use .local

There are several suggestions below, including a Microsoft file to overcome a renaming problem.

January 2, 2004
Bart Scholten

We are also trying to have the Mac OS X Panther Macs joining the Active Directory (named .local), but also get the invalid domain/forest message. In reading through the Directory Access help files, I noticed that the AD plugin uses LDAP for user account access. Does this mean that LDAP has to be enabled on the AD server? Nobody seems to mention this, even though I remember having read that LDAP should be enabled on the AD server, but that was before the AD plugin in Panther. Maybe though the same is true for the AD plugin? We do not have the test setup yet, to experiment with the AD server, but maybe somone has tried that?

January 6, 2004
Adrian Cooke

Thursby's ADmitMac works well. However, working for a company with 70+ Macs, ADmitMac is not an option because of price.

These are the main problems that I see with the Panther AD plugin:

January 7, 2004
Santino Rizzo

I've never had a problem connecting to member servers with a single sign-on.

The network browsing problems have nothing to do with the AD plug-in. Windows server login script are .bat files which Mac OS X doesn't understand, again nothing to do with the AD -plug-in.

January 12, 2004
Nick Davidson offers challengesAdrian Cooke previous assertion that Panther's Active Directory features have no ability the mount multiple volumes from any form of Windows server login script. Davidson provides some guidance:

Mounting Multiple Volumes using a Windows Server Login Script.

First, the login script file will have to be a Windows file using the standard Windows file format. In other word, it will need a CR LF at the end of each line; otherwise, it will only execute the first line of the script.

Second, the login script file will need the proper permissions for the remote Windows computer to execute the script.

January 5, 2004
Josh Wisenbaker

This is getting a lot of people stuck. The problem seems to be with .local, which is what ZeroConf, i.e. Rendezvous, uses for name resolution. Here is a snippet from the Mac OS X Server mailing list:
The only solution I know is to create a new Active Directory domain and migrate to it. This is biting a lot of people. The problem is that Microsoft's AD documentation happened to use an example domain name that uses just about the ONLY illegal suffix. Lots of people followed the example to the letter...

Also the AD plugin is going to use LDAP for account info as AD is an LDAP server with extra bits thrown in. You don't need to do anything different on the server.

January 5, 2004
Tony Trumbo points to an Apple KnowldedgeBase article 107800:

I noticed on your site today a posting from someone having difficulty using AD integration with a .local domain name. Unfortunately this person will not be able to try the integration. Many MCSE's were told by trainers to use a .local top level domain name for internal domain structures. Unfortunately .local is used by the Multicast DNS standard, part of Rendezvous. Article 107800, from Apple shows how to allow host lookups on .local domains. But to get full integration they will need to change their AD domain name. This is really only possible once you have upgraded domain controllers to Win 2003 and Exchange 2003. I know because I am dealing with this right now.

January 5, 2004
Henry Stukenborg points to the same article and its applicability to the plugin.

You currently (as of 10.3.2) cannot bind to AD domains using a .local suffix because of the conflict with Rendezvous. Apple provided a workaround to this (KnowldedgeBase article 107800); however, it doesn't work for the AD plug-in. Apple knows about the problem and it should get fixed in a future update.

> Does this mean that LDAP has to be enabled on the AD server? ... Maybe though the same is true for the AD plugin?

Now I could be wrong, but to my knowledge you can't disable LDAP on AD. I'll defer that to others. Now as to the AD plug-in, it does indeed use LDAP and Kerberos when communicating with Active Directory; so if you've somehow disabled (or blocked) LDAP on the AD servers, you'll need to correct that or it won't work.

January 5, 2004
Robert Dalgleish:

You describe a situation where the the Active Directory domain is ".local". If this means that machines have fully qualified domain names ending in ".local", then you are out of luck. The ".local" domain is essentially reserved by Internet standards for Rendezvous (a suite of standards that allow minimal configuration of new machines). Any reference to a ".local" host will get routed through the Rendezvous resolution procedure instead of the DNS (or AD), so they won't be found. There are published methods for getting around Rendezvous, but I believe that they also disable some other useful features.

The simplest solution is to change the Active Directory domain to something more useful.

January 5, 2004
David Ensteness:

When you do the reverse, authenticate Windows clients to Mac OS X Server v.10.3. you must have the Mac OS X Server running as an Open Directory Master and a PDC in order for it to work. While I have not done it the other direction as you are (Mac OS X clients authenticating to an Active Directory Server) I imagine that you still need Open Directory access in order to properly authenticate. I can see your confusion those, since Directory Services allows for a Mac OS X client to talk directly to an ADS. I would still assume that LDAP should be enabled, however, because in the reverse instance I noted Mac OS X Server takes the data from the AD client and pumps it through its LDAP directory to authenticate. So it makes sense that Mac OS X clients need LDAP enabled on the ADS to authenticate to the domain properly.

TIP: A fix from Microsoft to a renaming problem

June 2, 2004
Tony Trumbo

I know there has been previous discussion on MacWindows about the use of .local in Active Directory domain names. Renaming the domain to end in something other than .local was possible with Windows 2003 but it wouldn't work if you had Exchange in the domain. Microsoft has just released a tool that now allows you to rename a domain with Exchange 2003 in the domain. The tool can be found at a Microsoft page called Exchange 2003: Domain Rename Fixup (XDR-Fixup).

Hope this is of some use to MacWindows readers.

TIP: Procedure for 10.3 Server, Open Directory and Windows Services integration.

January 22, 2004
Adam Glick of HelpDesk, Inc.

10.3 Server, Open Directory and Windows Services *will not work* as shipped.

The setup: 2 Brand new XServes, 10.3.2 Server. Migrating old NT server PDC to new 10.3 Server using Windows PDC functionality for a workgroup of 50 architects.

The goal: Migrate to OS X Server with PDC functionality using Open Directory (OD) and replicating using OD Master/Slave. Get door open a crack to get some G5's into the office.

The experience: Clean install 10.3 Server to Xserve. Use initial server setup to set up as Open Directory Master and Windows PDC.

Apply software updates to to get to Server 10.3.2, etc. Reboot. Go into Server Admin, notice that under 'Open Directory>Overview', 'KDC' lists status as 'Not running'. KDC is the Kerberos Key Distribution Center piece, which I was pretty sure is crucial to Open Directory authentication mechanisms. Confirm that the 'Windows' services are running and role is set to 'PDC' and enable the WINS feature. Try joining a laptop running Win2K to our test network with the Xserve as a PDC. No go. Yields a variety of error messages all of which seem to indicate that it cannot authenticate to join the NT domain. Try manually adding machine record in Workgroup Manager. Still no. As a double check, do a quick clean reinstall and re-setup of OD, etc. Same results. KDC is still 'not running'. Break down and RTFM. Checked Apple's supplied PDF on setting up PDC, Open Directory, etc. Did everything that was listed first time around. Four hours spent at this point.

It's at this point I decide it's probably a good idea to take advantage of the Server Premium Support and confirm some hunches with the nice Apple Server tech:

1. As shipped, Open Directory will not work because DNS does not get set up, started or properly configured.

2. The Kerberos services are not set up and won't run until you tickle them from the command line. And if there's no DNS, you're buggered anyway.

3. The LDAP install as a result is bad as well, since it doesn't reference anything resolvable.

Anyone else's mind a little blown at this point? Apple is marketing 10.3 Server on it's ability to masquerade as a PDC. It *will not work* out of the box. Period. I've used OS X Server since that first scary version 1.0. I'd like to think they can do better than this by now. DNS is as crucial for OS X Server now as it was for 1.0.

This is what the Apple Tech sent me (which he had previously sent to another person), which does make it all work. He also sent a sample DNS.plist file to seed bind with defaults that can then be modified. He was very helpful and confessed that they are aware of this as an issue. I've removed his info from this clip:

"The IP address of the server ( which is 192.168.2.5 ) this would indicate that you are behind a router that is running NAT. This is a very common setup. In your situation you need to have DNS setup behind your router in order for the LDAP domain to work properly ( LDAP relies heavily on DNS). I have included a sample DNS Configuration file "DNS Configuration.plist" . This file is setup with the appropriate IP information according to your network . In the file the server's hostname is "server.example.com" .

To get a simple DNS setup running you must open server admin and then go to the DNS service. Under the DNS service click on settings and then zones and drag the "DNS Configuration.plist" to the server admin window. All of the zone information will populate. You can click through the zones on the left to view the information. Once you have verified that all of the information is entered , you can start the DNS service.

Once the DNS service is running, you will want to verify that DNS is working properly. To do this open the terminal ( which is located in applications and utilities). Then type "nslookup" ( without the quotes of course). Once nslookup is up you will see a prompt that looks like this ">". At the prompt type in "server 192.168.2.5" then press return (this will set your default server to your machine temporarily).

After setting the server type your IP "192.168.2.5" then press return and it should return "server.example.com". This means that DNS is setup and working. You can at this point quit the terminal. The second part of this process is to point the server to itself for DNS resolution. You can do this by going to the System Preferences and then Network. Click on the Ethernet interface and for the "DNS Servers" field enter in your machine's IP at the top ( 192.168.2.5 ) and nothing else (apply those changes). Now your machine is pointed to itself for resolution. This means your machine now can resolve its hostname which we entered "server.example.com". (This is optional: When you set the machine to point to itself it will no longer be able to resolve Internet names like apple.com, thus the Internet will appear to not work. You can easily resolve this by adding forwarders. To add a forwarder you have to open up the terminal. Then we have to edit a config file and to do this type "sudo pico /etc/named.conf".

Here is a sample of the forwarders entry just replace the IPS listed with your ISP's nameserver's addresses)

###part of named.conf##

};

options {

directory "/var/named";

/*

* If there is a firewall between you and nameservers you want

* to talk to, you might need to uncomment the query-source

* directive below. Previous versions of BIND always asked

* questions using port 53, but BIND 8.1 uses an unprivileged

* port by default.

*/

// query-source address * port 53;

forwarders {

17.104.244.23;

17.34.100.3;

};

recursion true;

};

####### this file is listed below as well for reference in the named sample file ###

### When you are done editing the information hold control and the letter "o" and then return that will write the changes to this file.

At this point we need to configure the LDAP domain. Now these next steps will remove whatever user information (aside from the admin) that you entered in previously in your LDAPv3 domain. The first step is to set open directory to standalone server and save it ( you can do that by going to open directory in server admin -->settings and then standalone server). Once the server is standalone you need to open the terminal. We are going to now clear out whatever previous LDAP data was entered. in the terminal type "cd /var/db/openldap" then return. Once you have done this you will be in the openldap directory . Type "ls" ( this list the contents of the directory). Then you should see "openldap-data" in the list make sure that this is the case. Then type " sudo rm -r * " ( note: there is actually a star or shift 8 (*) after the -r ) you will have to enter in the admin password. This will delete the contents of the directory that you are in which should be /var/db/openldap. After doing this quit the terminal. Open up server admin and go to open directory. Set the machine to an Open Directory master. The drop down menu will pull up. Enter in your admin users shortname and password (do not enter in the information for the root user). The Kerberos realm name should be your hostname in all capital letters ( if this is not populated enter in "SERVER.EXAMPLE.COM" ). The search base will also be listed below this should automatically populate ( if not enter in "dc=example,dc=com"). Once all of the appropriate information is entered press ok. This may take a minute. You can check progress by going to protocols and then LDAP . All of the information in the protocols tab should be filed in search base and database ( make sure that this is the case) . Once this is filled in you have an LDAP domain. Go to workgroup manager then make sure you are authenticated to the /LDAPv3/127.0.0.1 domain. If not there may be some issues with the password type of the administrator before creating the domain. If its still not working correctly you need to go to the local domain /netinfo/root within Workgroup manager and click the admin which is user id 501 and then check the advanced tab and the password type this should be open directory with a long key of 1x000000000 or something similar to this. If not you can repeat the steps to remove the LDAP domain set it back to standalone and then run the "sudo NeST -hostpasswordserver adminname adminpass". This will change the admin password type to open directory ( after this is set then you can remove the LDAP domain using the instructions above and also set it to open directory master again and the admin should be able to login.). I hope that this information is helpful . If you have questions regarding this issue please email me back . Note apple doesn't offer DNS support under the 90 days of support that is provided with the OS X Server product . The information in this email goes beyond what we normally offer. This just means if you call back they will not be able to assist you with DNS setup. Thanks for your time." -Apple tech

On top of this, you'll need to do the kerberosautosetup and kdc setup as outlined in the man pages for kdcsetup.

So, I wade through all that. Finally, KDC is 'Running'. There was one last glitch where the admin account could not log into Workgroup Manager, and if you can't do that the password hash didn't make it over. Redo the LDAP hosing part, and redo the NeST command. If you can log into Workgroup Manager as Admin to the LDAP domain you're good. Test laptop joining domain. Cross fingers, perform mojo...it works!

Problem with Microsoft Distributed File Service

February 16, 2004
Klaus Banse has a problem with Microsoft Distributed File Service:

We were successful in getting authentication through Active Directory. It was quite simple using the Panther AD plugin in Directory Access. The unfortunate part is, our PC server uses Microsoft Distributed File Service or DFS. That doesn't work with Panther. We can't see any of the shares. We could use ADmitMac but unfortunately, we don't want to spend that much on a file browser. Any suggestions?

If you can offer advice or have had a similar experience,

Binding Issues with AD

TIP: Binding to Active Directory with Panther (OS X 10.3)

February 16, 2004
Emil Lundberg of Sweden has some suggestions for successful binding to Active Directory:

The two gotchas I've seen so far in binding Panther to AD:

1) If you're using ".local" for top AD domain (the horror!), the aforementioned fix from Apple will indeed make Panther query the DNS in the correct way (you will still see Rendezvous multicast traffic, but never mind).

2) If, however, you are using ANY nonofficial top domain (.local, .myowndomain, etc) for your AD (and many will, as the local IT department might not want to see their DNS servers replaced by Windows machines), you HAVE to make sure there is a reverse lookup entry to match you server (i.e. if your server is adserver.example.mydomain and maps itself to 123.234.123.2, then 123.234.123.2 MUST map to adserver.example.mydomain). If not, you'll be stuck with "Invalid Forest and Domain combination" forever. This can be accomplished in two ways:

a) (More difficult) Talk the IT department into delegating the responsibility for your subnet (e.g. 123.234.123.x) to your AD-server(s). This might be more than you can chew, so

b) (Easier) Have an entry for each of your AD servers added to the "official" reverse zone (again, e.g. 123.234.123.x), keeping the official name in place. Thus the server 123.234.123.2 will have the following PTR records:

123.234.123.2 PTR adserver.example.realdomain.

123.234.123.2 PTR adserver.example.mydomain.

AD binding is a matter of seconds after this. Haven't seen any detrimental effects of the double of records so far (actually, DNS seems to send both names back).

Mac OS X 10.3.4, 10.3.5 "forgets" binding to AD.

August 2, 2004
David Erdely reports a problem with binding with awith Mac OS X 10.3.4.

I run about 40 Macs on a network of a little over 1000 PC's. I have them logging into our AD domain. I had no problems under 10.3.3 but after upgrading to 10.3.4 our machines seem to "forget" that they are bound to the domain. I cannot unbind them, that freezes up the machine.

I actually have to go into single user mode and delete the ActiveDirectory.plist, SearchNodeConfig.plist and ContactsNodeConfig.plist to remove the machine from the domain. At that point I can rejoin the domain and have no problems, except that the machine will forget that it was joined to the domain after another few days or a week.

September 10, 2004
Nicholas Wojtowicz

We are having a very similar issue on my campus. This is what happens.

I have 2 Mac labs with 34 machines, and an odd number of Macs for faculty/staff throughout campus. I bind the computers to out Active Directory and then use our Xserve for policies and privileges. This procedure works fine. At random, a computer seems to forget that it is bound to our active directory and thus it will not allow a user to login because it does not authenticate against the active directory.

To fix this, I have to delete the Directory Services folders' contents, restart the computer and then rejoin it to the domain.

If you've seen this problem

October 27, 2004
Some problems with Mac clients and Windows servers are universal in nature, but there is at least one issue this is truly global. Holly Troy of McMurdo Station, Antarctica, reports seeing this problem:

I have seen this issue down here at McMurdo Station Antarctica and its got me really ticked off because it was stable at 10.3.3, no issues. I am thinking they broke it with either a security update or .4 or .5 release.

Also if you just do a reboot it fixes the problem 90 percent of the time and waiting for the AD services to register upon boot up.

Next, we discovered that this issue does not happen on our G5s but is pretty common on our G4s. Is that weird or what.

Apparently, the Apple is aware of the issue and is working on a fix for possibly 10.3.6.

If you're curious about what goes on in McMurdo Station, you'll find a short video here.

This is actually the second report we've received from Antarctica. The first was in 1999, from Dean Klein, who was an IT manager at Palmer Station.

Suggestions

If you can verify or dispute any of these suggestions

September 15, 2004
Dag Tore Antonsen seems to have the most successful suggestion:

At my office, we have about 600 Macs and have seen the same problem where some machines randomly forget that they are bound to Active Directory. It seems that all of these problems are related to restarting the computer and often related to installing software through Apple's Software Update.

My solution to the problem seems to help if you have a local user (we have a NetInfo "administrator" on each machine") and log in as the administrator. Log out, and then log into your active directory account. Another restart also solves the problem in 99 percent of the cases.

The problem might also occur if you try to log on to the machine just as the machine has booted. Wait a couple of minutes, and it should be fine.

We leave our lab-machines turned on 24-7, and it usually works great.

September 15, 2004
Brad Anderson

I too have seen this happen in the studio I support. To be honest, it just happened to my 15" PowerBook last night! The only way to fix this is to delete the Directory Services prefs, then bind to Active Directory again. I am using 10.3.5 across all my Macs (about 10 of them).

September 15, 2004
Gilles Cordier

We are facing to the same problems. After a while some machine couldn't connect to AD anymore.

Are the readers with this problem in a mixed environment (NT/2K)? We are in this situation and we ask us if sometimes the validation failed when it occurs on NT backup controller. Maybe could we go ahead in this way?

September 20, 2004
Joann Williamson writes:

We are experiencing this problem, too. We are using Windows 2003 servers as our Domain Controllers with Active Directory. We found that if a Mac "forgets" that it is bound to AD, we can just unbind it and bind it back again. We have not been deleting the folders like you mentioned.

September 20, 2004
Ted Kim discribes the relationship of this issue to DNS:

I have found this problem really only on my Xserve server. Running MacOS X Server 10.3.5, I have seen this problem. I setup Directory Access to bind to Active Directory, and successfully setup my Open Directory Server and Workgroup Manager. I then come back to it, as quickly as ten minutes, and my server has lost all connection to Active Directory. I cannot unbind or access users from my existing Active Directory. I go in delete the Directory Access-centric .plists, reboot, and rebind.

I have found that if you do not use DNS or have a strange DNS setup, this problem abounds. I ended up having to enable DNS on my XServe and make it a slave to my primary AD-Integrated DNS server, and this seems to have solved the issue. My server does not seem to be losing connection to my existing AD setup.

I have not had a problem with any client machines I have setup since my primary DNS server is also my AD-Integrated DNS Server.

Another thought: Open Directory is even more finicky about DNS than Active Directory. AD requires a "AD-integrated" DNS server that supports not only forward-looking zones, but also reverse-looking zones. But AD only requires one DNS server that meets the above requirements. OpenDirectory requires a DNS Server on each Open Directory server. I have not had an opportunity to test whether that is only a Master or not. The DNS Server on the Open Directory thankfully can be a slave that replicates from a central authoritative DNS server, but still requires it. That may be the crux of many of the problems that users are experiencing with AD-Open Directory integration.

September 20, 2004
James Hanback found that spanning tree settings were related to the problem:

I encountered this issue from time to time even on computers bound to AD Panther versions earlier than 10.3.5. It appears that the Spanning Tree Protocol settings on my network switches were at least partially to blame for this issue.

The STP on my switches produces a 30-second activity delay from the time a link is established between node and switch. This is normal behavior for those switches (Cisco Catalyst 2970 10/100/1000), but it also means connectivity to the network isn't established until *after* Panther boots to the Login Window and the user has attempted to log in.

On my Windows machines, this was never a problem because the NICs are connected even when the computer is not on. The Macs shut down NICs and all.

Unless a Panther user cache happened to exist, the lack of connectivity resulted in the Login Window shake-off. If a user cache *did* exist, the user could log in but single-pass authentication didn't work because the Kerberos ticket wasn't renewed.

Enabling the PortFast option on the switch ports to which my Macs are connected (which establishes connectivity immediately upon link) resolved this issue.

If can comment on these or previous suggestions,

AD binding problems with the 10.3.3 update

We've had many reports of this problem. After these reports are some reader suggestions.

Readers also report that the 10.3.4 update fixes this problem.

The problem

March 18, 2004
Jay Christianson can't bind to Active Directory with the 10.3.3 update:

Not sure anyone else has brought this up, but on machines that we have upgraded to 10.3.3, we can not bind them through Directory access to Active Directory.

I believe machines that were already bound, and then were upgraded are still working correctly. It's just machines that we hadn't bound prior to going to 10.3.3 that we can't make bind.

March 18, 2004
David Toub also reports an Active Directory binding problem:

John, there is definitely a change with 10.3.3, but I'm not able to say, unfortunately, that I've successfully gotten network access with this update. Prior to a recent Windows network update, I was able to log on to our network under 10.2-10.3. However, since the update, I have not been granted authentication by the network under Active Directory. I was able to do this using ADmitMac from Thursby, but that trial expired. With 10.3-10.3.2, the Active Directory tab of Directory Access would not recognize our domain. Under 10.3.3, I get much further into the process-I do get through most of the binding process, but in the end I receive an error message that I don't have administrative privileges, which I assume is on the network since I'm the system administrator on my own iBook. Strange that this was not at all an issue with ADmitMac. I think 10.3.3 is a step in the right direction, but for our network at least, it's not there yet with regard to AD.

March 23, 2004
Bill Steigerwald

We have the same issue. We also found that the computer cannot already exist in the AD. When using a new computer name it creates it in the OU and never finishes the bind process.

March 23, 2004
Sébastien Dreyfuss

I have just upgraded a PB to 10.3.3 and the same problem David Toub described: the machine won't bind because I don't have sufficient privileges. At first, I thought it was my local account, so I logged in as root, to no avail. Secondly, I asked the Domain Admins to use their own login and password, still to avail.

Under 10.3.2, I was able to bind, but not authenticate a user in the domain. As I read that 10.3.3 brought a new version of the AD plug-in, I tried a newly upgraded machine, but I can't even pass the binding process.

We are running AD on a Windows 2000 Server.

March 23, 2004
Frank Houle sees the "Insufficient privileges" message:

I can no longer bind any Mac to AD. I always get "Insufficient privileges" even though I'm an AD admin as well as the main admin on the computer. Have not been able to find what the issue was. Maybe a combination of the Mac 10.3.3 update and a windows server update conflicting?

This more or less worked as I was able to bind to AD once I had created the Computer item in the right OU. I was only once able to bind in a proper manner (ie any user could login through my test machine), but I had to play with it and broke it. Ever since then I have been able to bind, but no other user could log on to the machine. It would not be able to find their ID info. As of now, I'm still trying to figure out what made it so that now it does not work. I've reinstalled the OS from nothing even.

Right now, I'm stumped. A lookupd -d will show a list of seemingly random users once I bidn, but no user that I can recognize even though I'm bound to that specific OU and I can see the Computer item listed in the AD Users and Computers on my XP machine. It never does put its DNS name or anything.

I even tried following the instructions on how to Bind properly to AD from different sites still not to avail.

Today, a new problem popped up. Now it will not let me bind the Mac to AD. It states that I don't have sufficient privileges, even though I'm very well listed as an Admin and can login to AD on windows machines.

I'm also wondering if it may be a kerberos issue where the kerberos ticket is not being created or send to the AD server.

Trevor Teuscher cannot find a solution:

Where I work, we have also had problems with the 10.3.3 update and active directory. Before the update, we could bind to Active Directory just fine. After the update, we are no longer able to bind. Further, we are unable to authenticate to the Active Directory server from machines that we were able to authenticate to prior to installing the update. Our Active Directory administrators found a way for us to bind from computers that have been updated by using a different address for the forest. However, the only way this has been successful, has been to unbind the computer BEFORE running the update and binding again AFTER the update has been installed. The computers the were not unbound before running the update are stuck. We can no longer unbind them, let alone rebind the using the new forest address. So far, we can't find a workaround.

March 23, 2004
Andrew Lee:

My problem may be similar to Jay Christianson's, who said
[Our] machines that were already bound, and then were upgraded are still working correctly. It's just machines that we hadn't bound prior to going to 10.3.3 that we can't make bind.

I have configured 12 Macs to authenticate from our Active Directory server using the directory access plug-in. Two have been upgraded to 10.3.3 now and both seem to have broken. It did not happen straight away, so I am not convinced that it is the update that broke them. At the same time I was updating them, one of our other administrators was trying to trouble shoot a windows login issue that is plaguing many of our Citrix clients. He ran several active directory repair processes which may have contributed to our current situation.

The situation:

The two machines that have been updated stopped authenticating against the server - not straight away, but 2 or 3 days later. On one machine I attempted to unbind from the server and then rebind. Unfortunately I am not able to unbind the machine. It is kind of in limbo at present. OS X thinks it is part of the AD and I am trying to find out how to reset this.

As a result I am not game to upgrade the other 10 machines in case it is the 10.3.3 update that is breaking things.

March 23, 2004
Bruce Nunn describes problems with XServ server:

I'm experiencing a similar problem that David Toub has written up, only worse. Our PC geniuses recently added a Server 2003 to the network as a backup domain controller to a Windows 2000 PDC, with the honorable intention of replacing the old Win2K server as primary domain controller. And that included adding a new Active Directory scheme and add-on to the old PDC.

Suddenly, my XServ (with 10.3.2 at that point) would go into a spin and reboot every time I tried to start Server Admin. Also, connecting to shares in active directory-connected servers from the XServ would eventually cause a spin /crash/reboot also. Since I'm yet Unix literate I couldn't figure out how to turn off some of the server services on the XServ that were probably crashing into Active Directory bugs. Sooooo, I reloaded the XServ, did all updates to 10.3.3, BUT only left one admin logon with an Open Directory password -- all others are set for Shadow Password - and I absolutely do not use that OD logon now, as it'll crash and burn the system if there's interaction with Active Directory in the MS Domain realm; I also disconnected the XServ from the company DNS service, and went straight out to one of our service provider DNS addresses for Xserv software updates etc. Now the XServ works great, faster than before apparently for Mac clients, and the Mac clients can still connect to the PC servers for Entourage email & calendaring (using POP not IMAP protocol -- which the MS servers sort-of/kind-of use but with an MS twist to the IMAP standard, of course) and also connect to Mac-shares on those servers; I've turned off the SMB on most of the Mac clients, as it slows their networking down a bit (they were networking as slow as local PCs which connect to the Active Directory domain) and I figured out I just didn't need the feature usually anyway.

I'm not totally sure at this point if MS did a number on Apple here, or if our PC admins just did a shoddy job. It really looks like both. I can't fault Apple here as the MS changes in Active Directory goofed things up immediately upon installation, AND I can easily connect from Mac clients to a dozen or so PCs under my control (when I want to); these dirty dozen PC are not allowed to authenticate to the often-virused MS Win2K/2003 domain as a domain member as I don't have time to remove the latest & greatest viruses every other week (still happens but not as often as before).

I noticed that networking had changed by both the XServ crashing AND some power-users on Macs finding networking glitches and getting random spinning-wheel-from-hell delays. In addition, my assistant started running into weird problems in doing large copies (2 GB)of Mac programs & font sets from a PC Server share to new OS X 10.3.2 G5s, as the copying would stop with a message about some random file already existing could not be overwritten because it was in use. The PC admins claimed they didn't do anything, nothing changed, it had to be a Mac problem, but they finally confessed when the PC backups kept failing -- with critical backups of PC servers -- with authentication problems that, yeah, now that they thought about it, they did change a couple little things. I nominated them for starring roles in local Passion plays, but HR wouldn't allow it.

I really loved the SMB connection options a few months back, but I've since realized it's smarter, safer, and faster to turn off SMB whenever possible, and to keep all critical PCs disconnected from the MS domain as much as possible as well. SMB is mostly a great new toy at first, but really belongs in the old toy box. My advice is keep things as separate as possible, don't use IMAP protocol, use MS Remote Desktop to manage PC Servers from a Mac, and keep your spikes sharp.

Suggestions

March 23, 2004
Joseph Swenson had this to say:

We saw the permissions error as well, however we then specified a Domain Controller, and we could bind the machine without error. After binding we unchecked the preferred domain controller option, and everything has worked fine.

We've also noticed kerberos authentication is working for SMB connections.

March 23, 2004
Blair Hicks succeeded when he enabled "guest" in the domain:

Using 10.3.3 with Active Directory now can browse correctly, but only after I enabled the Guest account on the domain controller.

Before "Guest" was enabled I would see a security event log basically saying that the 10.3.3 computer was trying to use the guest account. This is after a successful login using a AD account.  

The 10.3.3 computer should be using the logged in user information to make and connections to AD.

10.3.3 also fixes the "Kerberos Ticket" security events that would show up before.

March 23, 2004
Through some trial and error, Craig Nicko managed to get a binding:

I've recently upgraded to 10.3.3. For a computer bound prior to the update to 10.3.3, no problems. I then make a disk image and move the entire installation to another machine, unbind AD and rebind with a new computer name. My first attempts failed to bind with the new name citing that the account is not authorized for such actions. Of course I'm using an AD domain admin account to bind. Tried three or four times to no avail.

Then on a whim, I shortened the computer name and tried again--same domain, same admin account credentials, and it worked. I'm testing more to see if this is just coincidental erratic behavior or if the computer name length does have any impact. Until I do further testing I won't know for sure. But, for the record, this format worked:

AAAA-AAaaaaaaa-aAaa

But this didn't:

AAA-Aaaaaaaaa-AAaAaa

March 25, 2004 --. A recently updated Apple Knowledge Base article entitled How to Look Up ".local" Hostnames via Both Rendezvous and Standard DNS provides a Unix shell script that will enable standard DNS to look up Rendezvous .local names. The script, from Article 107800:

$ sudo su
$ cd /usr/sbin
$ cat > EnableUnicastDotLocal
#!/bin/tcsh
echo domain local > /etc/resolver/local.1
grep -v domain /etc/resolv.conf >> /etc/resolver/local.1
echo search_order 2 >> /etc/resolver/local.1
[Control-D]
$ chmod +x EnableUnicastDotLocal
$ exit

These steps create an executable shell script named "EnableUnicastDotLocal" that will create and populate the necessary configuration files to enable dual lookups of .local hostnames.

To run the script, execute this command:

$ sudo /usr/sbin/EnableUnicastDotLocal

March 25, 2004 David Toub, one of the first people to report the Mac OS X 10.3.3 problem with Active Directory binding, sent an update. He has tried the AD binding suggestions on our Active Directory Reports page, without success:

I read with interest the numerous comments regarding this issue in the March 23 MacWindows. I also saw a comment on MacFixit regarding the need for a shared folder on the target drive in order for it to be recognized under 10.3.3. I went through and attempted most of the potential solutions, including making sure there is a shared folder on the network drive in question (there is), deleting my AD account and recreating it, trying to log in as Guest, etc. Unfortunately, nothing worked--I still get through 4 of the 5 steps in binding, but in the end get the same error message about not having privileges to do this.

This, along with the inability to use ifconfig or the Network preference pane to change my network interface settings to full-duplex (broken as of 10.2.8--all this does is terminate my network access forcing me to reboot) has really loused up my ability to use my iBook at work on a Windows 2003 network.

I've heard this from others in similar situations, and feel like things were better in 10.2.6 than the current system as regards network access. I'd like to think that Apple is aware of this (I had informed Apple tech support about this some time ago) and working on a fix, but it needs to happen sooner rather than later, as it is getting harder to be the only Mac on a network these days.

The role of .local domain in AD binding

March 23, 2004
Mark Edwards is also wondering about the .local domain:

I was really thrilled when I read that Panther 10.3.3 had resolved the problem of binding to .local domains so I updated and tried again and got exactly the same error as before - that it couldn't bind and that I should use a FQDN. Has anyone else managed to bind to a .local domain with 10.3.3?

Previously, I have been using both Panther (10.3.2) and Jaguar with ADmitMac to try and integrate with AD (Win 2000 server)

Both worked fine with a test.com domain, but failed to bind to test.local. I tried all 'fixes' I could find - disabling mDNSResponder, hacking resolver/local to point to our DNS and installing dotlocallocator. All these failed.

I wrote to Thursby who said they 'had no timeframe' for fixing the .local problem.

March 23, 2004
Will Jorgensen

I have experienced the same problem with the Active Directory plugin as previously mentioned. On machines that were upgraded the plugin ceases to work. If I remove the search path for authentication and contacts and then re-added the plugin into the paths it continues to work.

However, binding is a problem. If I unbind a computer that was working and then try to bind again I get an error message that says I have an invalid forest domain combination and asks me to enter a fully qualified domain name, presumably new computers would have the same problem. I have confirmed with our Active Directory admins that what I am putting in is correct. (The same information that I was using in 10.3.2 that worked) I'm not sure what apple changed here. I think it has something to do with the additional compatibility that 10.3.3 is supposed to provide with .local domain environments since our forest uses a .local address.

In response to another users comments about getting all the way through the bind process and then getting an error. I believe the problem is that your network account doesn't have permissions to create the container in AD or the container exists already (maybe created by ADmitMac) and you don't have permissions to join a new computer to that name. I have seen a similar problem and deleting the computer account in AD fixed it for me. I have had to add the computer accounts for other users that were trying the plugin but didn't have permissions in AD to create computer accounts.

March 25, 2004
Mark Edwards

Well I've finally got 10.3.3 after applying this fix I found on the Apple site which shows How to Look Up ".local" Hostnames via Both Rendezvous and Standard DNS.

More suggestions for binding

March 30, 2004
Mark Fojas

David is apparently mistaking his local admin privileges on his laptop

for domain admin privileges. He will not be able to properly bind to to AD unless he is in the domain admin groups-- and this is controlled by the AD administrators. I have been able to bind and unbind at will-- because I am a Domain Administrator. He should request that one of his company's AD administrators to bind his computer. If he has an AD account, he should be using that account instead of his local laptop account. Note that he should type in his username as

"<domain>/<username>.

*<domain>=his organization's domain/<username>=his AD account.

My experiences with AD and OS X integration have been great, of course, I have a lot more privileges than most people on the domain. Get to know your administrator. Let him play with your toys.

March 30, 2004
Peter Jensen

I got the same authentication error when binding OS X 10.3.3 to AD on Windows 2000 Server, but found that entering the AD server as the only DNS server in the System Preferences Network configuration solved the problem.

April 12, 2004
Will Jorgensen sent an update to his previous report:

I previously reported problems binding to our AD domain when 10.3.3 was installed. I have tried Apple's fix and I am still not able to bind to the domain. I get the exact same error message about needing a FQDN. I can get bound to the domain by booting to a 10.3.2 drive, binding under the appropriate computer name and moving the AD plugin files found in the /Library/Preferences/DirectoryServices folder over to the 10.3.3 disk. This however doesn't work as well as I'd like since every time I reboot I have to initially log into a local account, then do a search in AD using Address Book. After doing that, I can log out and log in using my network account.

April 12, 2004
Shane Palmer tried some of the suggestions from other readers, but they did not work. Then he discovered that the Unbind action deleted the computer account form the Active Directory:

I too am having problems with binding to Active Directory after updating to Mac OS X 10.3.3. I also have Domain Admin rights, but contrary to Mark Fojas' experience I am no longer able to bind Macs to Active Directory. I get the error that I have insufficient privileges. The key point here is that, regardless of how our Active Directory is set up and the procedures I use to bind to AD, I was able to do this with Mac OS X 10.3.2 but after upgrading to Mac OS X 10.3.3 and using the exact same steps I am no longer able to bind to AD. Like other users pointed out if my Mac was already bound to AD before the 10.3.3 update I can still use my AD credentials to login. I have not attempted to unbind my main Mac as I am afraid I won't be able to bind it again unless I reinstall 10.3.2.

I also tried Peter Jensen's tip but it did not help.

After some more testing, I am still not able to get 10.3.3 to work with our Active Directory environment, but I did notice a behavior that some people may not be expecting. I had an install of 10.3.2 that I had successfully added to Active Directory and did an Unbind on it through Directory Access utility. I rebooted the machine and did a Bind again to add it back to AD but got the same "Insufficient Privileges..." message that 10.3.3 gets.

After several more attempts I realized that the Unbind action actually deleted the Computer Account from the AD. This took me by surprise because this is not typical behavior when you remove a PC from AD. I added the Computer Account back in AD and it worked fine. I did however have to reboot my Mac and wait a few minutes for AD to synch everything up before it would successfully Bind again. This may solve some problems a few people were having when trying to rebind their Mac to AD.

I submitted a bug report to http://www.apple.com/macosx/feedback/ and suggest that anybody else still having trouble submit a bug report as well.

April 20, 2004
John Blase

I found a workaround to the problems with my Active Directory binding procedure in 10.3.3:

I had to use a 10.3.0 computer to bind the computer name. Once it was bound, I bound the 10.3.3 computer using the SAME computer name, and it bound properly. I could then unbind the 10.3.0 computer, and the 10.3.3 stayed bound.

The computer name MUST be created in Active Directory first, before the binding will work.

The authentication works great, and everything seems to be hunky dory!

May 4, 2004
Don Clark verified John Blase' workaround:

I booted to a 10.3.2 partition on a FireWire drive to perform the workaround you described and it worked perfectly. Thanks for the tip!

July 21, 2004
John Parnaby

Users having AD binding problems with Windows 2000 and any version of 10.3 may be interested in our experiences... We found we suddenly were unable to bind Macs to our domain even though previously we could. A lengthy investigation with a lot of help from both Apple and Microsoft discovered the cause.

The bind 'process' involves the machine object having a password set by the Domain Controller. This is set when the account doing the bind sends a kpasswd request to the DC. This is the last of the 5 Apple steps that you see in the GUI when the AD plug-in is performing the bind - it echoes a message "Binding computer to the domain".

Obviously the account that is asking for the bind must have the rights to do the bind. In our case the accounts that make these requests are administrative users. It turns out that these users were members of a large number of groups - and this was the problem. Being a member of a large number of groups meant that the account requesting the bind had a "large" Kerberos ticket.

The ticket details are sent to the DC via UDP (TCP in Windows, but UDP for the Mac). A large ticket gets chopped up into fragments and a Windows 2000 DC will ignore fragmented UDP packets. Consequently the kpasswd request is ignored, the machine never gets its password set and the bind process times out.

Obviously at some point recently our admin accounts were added to too many groups and the bind stopped working. The interim workaround is to ensure the account doing the bind is not a member of too many groups. We're continuing the investigation to find out what the limit is in our environment and we should point out that this only appears to be with the bind process right now - user accounts changing passwords don't appear to be affected.

This may be worth investigating if you're having binding problems.

August 17, 2004
John Schumacher has another suggestion:

This week I was able to bind an Xserve (10.3.4, also worked after updating to 10.3.5) to our university's AD service, but there were two hurdles to get past. First, the network admins had to authorize me (my AD user ID and password) to add our server to AD's list of computers, which is the last user input before the OS X server attempts to bind to AD. My attempts to bind remained unsuccessful until I unchecked the option that maps the AD UID attribute to the Mac's uniqueID attribute. For whatever reason, ID mapping prevented binding.

If you've tried this

August 23, 2004
Josh Wisenbaker offered this about UID mapping:

There seems to be a bit of confusion here about the UID mapping option. It should be off by default and only used if you are specifically mapping the Mac UID to an entry in the AD user profile like "IP Phone." If you haven't set something like that up, then the option should not be checked.

Normally the AD plugin will generate a UID from the AD profile automatically. These might not be consistent for the same user from Mac to Mac though, hence the option to map them to something else in the AD profile.

August 30, 2004
Bill Davidson suspects that problem may be a licensing issue:

I suspect that AD binding problems may have something to do with licensing on a Windows 2003 domain controller in 2003 environments. This _may_ apply for Windows 2000 as well.

Lots of Mac/AD integrated shops are experiencing binding problems these days and we are curious if anyone has noticed that because bound Macs show up as servers. Windows licensing requires you to handle it using the licensing administrative tool, and Macs can't connect and supply licensing info themselves.

No sure if this is the issue - but we're feeling hopeful. We're trying it and seeing if any more Macs unbind in the next week or so.

An Explanation of the binding problem

May 26, 2004
Shane Palmer

I had previously reported on problems with binding to AD in 10.3.3 and had tried many of the suggestions people had to no avail. However, I made some progress in understanding the problem thanks to the extremely helpful hint from Brent Westmoreland (reported on the MacWindows AD Instructions page,) of turning on the debug logging for AD.

After comparing these logs from 10.3.2 and 10.3.3 I found that the actual problem was when the AD Plugin attempted to set the password for the AD computer account as shown from the log entries below:

And it appears that it was not due to my privileges since the following log entry showed up many times during the attempted bind process:

I had tried many other ideas: granting myself Full Control of the computer account using Active Directory Users and Computers, resetting the account, synching my date/time against the Domain controller, etc. As I was in the process of yet again upgrading from 10.3.2 to 10.3.3 via Software Update I noticed that the 10.3.4 update was now out. I upgraded and now I am able to bind to Active Directory again with no problems.

10.3.4 Update fixes the binding problem (or does it?)

May 28, 2004
Brad Immanuel:

Just thought I would chime in and let you know that updating to 10.3.4 solved all my 10.3.3 AD binding and logging in issues.

May 28, 2004
David Toub:

You may recall that in previous versions of 10.3, I was not able to bind to my Active Directory setup. I'm happy to report that since updating to 10.3.4, binding works. I'm still unable to browse our network, but I suspect that is a matter of working with Kerberos, etc. and our network administrator. Clearly some good work has been done on the cross-platform networking side, which is great.

May 28, 2004
Shane Palmer:

I upgraded to the 10.3.4 update and now I am able to bind to Active Directory again with no problems.

July 27, 2004
Michael Yuen, however, says that a clean install of Mac OS X 10.3.4 broke his AD bindings:

About AD bindings, it seems there are problems with 10.3.4. The binding process finished without any error message, but upon restart, it would not be able to logon using any domain credential. Strangely enough on the same Mac with 10.3.3 installed, everything is a go.

Upon further investigation, this symptoms only appears on clean install 10.3.4. On systems with 10.3.2 or 10.3.3 pre-bind and un-bind, upgraded to 10.3.4, works fine.

August 5, 2004
Jean-François Gaumond verifes that it is the clean install of Mac OS X 10.3.4 that causes binding problems:

I also have the exact same problem with a clean install 10.3.4 on new or older machines (G4's and G5's). Once bound on the AD, every user with the new installation, will receive the message at login that the home directory could not be found.

Had no problem with several older installations upgraded to 10.3.4. (from 10.2.x or 10.3.x)

TIP: A step-by-step Procedure for authenticating with Panther

February 16, 2004
Steve Dockery

In Jaguar, I looked around (in vain) for a good way to get the Mac to authenticate with Active Directory (AD) without having to purchase a third-party utility. When I got Panther, I hoped it would be as simple to connect to AD as it is with a Windows machine (which is pretty straightforward). It was not. I'm not an Active Directory expert at all, and everything seems to expect you to know about search bases, etc, which I knew nothing about.

I downloaded a demo version of ADmitMac, but because I got swamped with work, didn't have time to properly evaluate it before the demo time ran out.

Today I figured I'd try again with Panther. I looked up "Configuring Access to an Active Directory Domain" in Directory Access Help, and followed the directions. Here's what happened:

1. I opened Directory Access, made sure Active Directory was checked, and double-clicked it.

2. For the both the AD forest and the AD domain, I put in our network domain (our servers are running WINS and DNS).

3. For the computer ID, I put in the (short) name that I use to log onto our windows server and exchange email, both of which authenticate with AD.

4. I clicked BIND, and supplied it with my same short name and my password. Then, the tricky part. I guessed, based on the example, what to put in as the computer OU. I put in

"CN=Computers,DC=ourdomainname,DC=com"

5. I clicked OK, and it successfully bound to our AD server. I did not have to do anything to LDAPv3, I left it alone.

Now any user can log into my machine, and it will create a home folder on my machine for that user. While logged in as that user, the user appears in the Accounts preferences pane as a "network user," but they are not permanently added as a user. Once they log out, the user account goes away, but the home folder remains, pretty much just like it works on Windows.

However, I discovered my password would now no longer work for the server or email. I had to go to the server, log in as the admin, and reset my password (God knows what it got changed to when I did the BIND, or why, I use the same password everyplace).

After I set all this up, I looked in the AD Users and Computers on the AD server, and my computer name from the Sharing Preferences Pane was there.

When we roll out Panther on all our Macs in the next few months, I'll just create an admin account on each of them, and set up AD, then I can centrally manage users and passwords like I do with our PCs.

OS X users can't delete Trash

NOTE: On November 10, 2004, Henrik Ahlberg of Sweden reporte that the Mac OS X 10.3.6 update fixed the problem

The problem

April 20, 2004
April Acker

I see my postings on MacWindows have gotten a few very helpful responses, as well as some sympathy from users experiencing similar issues. The bad news is that I have not seen a decrease in the number of lockouts, despite much troubleshooting and server tweaking. However, with office 2004 a few short months away, hopefully the bulk of the lockout problems may soon be behind us.

Now I have run into another issue:

About a week after one of the users was migrated to OS X, he was unable to empty his trash. The issue was not that an item in the trash was preventing him from emptying it (I got no message saying an item was in use, for example). Instead, OS X verifies that the user wants to empty the trash, and by all outward appearances seems to go through the motions of emptying the trash. However, the files stay in the trash!

I started by fixing the permissions on his trash, and then by repairing permissions on the drive. I tried just about everything in the book to fix the "stubborn trash" issue. I even wiped the drive and reinstalled everything from scratch. Finally, I tested additional users. A local user on his machine can empty the trash, and I discovered that so can another active directory user.

Here's the kicker: when I log the problem user onto the domain using another machine, he cannot empty the trash ON THAT MACHINE EITHER. A second user began experiencing this issue shortly after we upgraded him to OS X, and the exact same is true of him. if I log him in to a brand new machine, the trash cannot be emptied there either.

This is clearly not an OS X permissions issue, but something tied to the AD account. Perhaps it is something that does not exist on the Windows client side, but when translated through Panther manifests itself this way? FYI we use 2000 servers. I am stumped.

If you've seen this problem,

Workarounds

April 27, 2004
Roy Atkinson uses Terminal:

Yes, we are seeing exactly the same issue here. Some users cannot empty Trash when logged into any Mac on the domain, while others can do it freely.

The Trash can be emptied from the command line (without sudo, which is puzzling as well). We are creating a script for users who don't want to use the command line until we find a permanent solution.

April 27, 2004
Allan Soerensen basically does the same, but uses a GUI interface with the $10 Cocktail utility:

Same problem here. About 50 Mac clients and a Win 2000 server. I solved the problem using Cocktail's build-in feature "Force empty trash". Works like a charm.

Merlins script to fix the trash emptying problem

May 4, 2004
Merlin Hartley

We also have the OS X with AD trash problem so I have written a little script - when double-clicked, this deletes the contents of the trash of the currently logged-in user.

Copy the contents between the ####s into a [plain text] document called:

"Empty My Trash.command"

#####################################

#!/bin/csh
# To Empty stubborn Trash
#
# written by Merlin Hartley 2004-04-20

# Padding for Prettyness!
echo ""
echo ""
echo ""

# Asking for Confirmation
echo "Are you sure you wish to remove all items from your Trash?"
echo 'Press "n" to cancel'
set cont = $<
if ( $cont == "n" ) then

echo "goodbye"
exit

endif

# Letting user know what is happening
echo "Removing all Trash contents"
rm -r ~/.Trash/*

# Padding for Prettyness!
echo ""
echo ""
echo ""
echo ""
echo ""
echo ""

# Echoing for friendliness
echo "Done"

#####################################

If this works for you,

Another fix: replace corrupt user account

June 2, 2004
Larry Jenkins

We have a large site using Active Directory authentication for over 1500 users. We have 160 Mac users using Active Directory authentication. We have experienced one Mac user that cannot empty the Trash when logged in using Active Directory authentication. This occurs for this user no matter which Mac he is logged into. Other Active Directory Accounts and local accounts can empty the trash on the same Macs. In the Active Directory profile for this problem user all the permissions seem identical to similar users. All members of the same groups, etc.

The fix was to delete the user account, clone a working account with the same permissions, and reattach the users Exchange (email) account to the new AD profile. The user can now empty the Trash.

It was a corrupt user account.

Platform specific?

June 2, 2004
Hugh Burt says the problem only affects Power Mac G4s:

I have also come across this and have found that it is a machine specific problem. In my experience it only effects Power Mac G4s. It does not seem to happen on iBooks, PowerBooks and iMacs (old or new).

June 8, 2004
Henrik Ahlberg, Sweden

We have had the earlier mentioned problems with "empty trash" for AD authenticated OS X users (10.3.3 and 10.3.4).

We have recently migrated from NT4 domain to a 2003 AD structure. 600 (250 Mac) users. "Old" accounts will not be able to empty their Trash, while with newly created accounts it works fine! We have also found this problem to be non-computer-specific... G4, G5, PB, G4 Xserve all acts the same...

Hugh Burt
June 8, 2004

I don't think it is anything to do with user accounts as I, using my AD account, can't empty the trash on G4s but can on iMacs.

Another tip for importing Address

Merlin's step-by-step guide to AD Integration in 10.3.3

April 27, 2004 -- Merlin Hartley sent us directions on integrating Macs with Active Directory:

Active Directory Integration for Mac OS X

1. Configure Active Directory Authentication.

2. Using 'Directory Access' from the Utilities folder:

A. Click the lock to authenticate
B. Double click on 'Active Directory'
C. Enter 'domain.co.uk' into both the 'Forest' and 'Domain' boxes (the DNS name of your Domain)
D. Enter the computers DNS name into the 'Computer ID' box
E. Goto 'Advanced Options'
F. Enable 'Cache last user'
G. Enable 'Authenticate in multiple domains'
H. Enable 'Prefer this domain server' and enter 'dc.domain.co.uk' (a domain controller in your Domain)
I. Enable 'Allow administration by' and enter 'Local Admins,Domain Admins, Enterprise Admins' ("Local Admins" is a group you can create in Active Directory to give specific users local admin rights on the OS X machine)
J. Click 'Bind' and authenticate using a Windows 'Domain Admin' account
K. On the 'Authentication' tab choose 'Custom Path'
L. Click 'Add' and select '/Active Directory/domain.co.uk'

3. Reboot the Mac and you should find 'Other' on the list of users.

Notes:

1. Logging-on as an AD user

2. Caveats, Bugbears and Gotchas

The empty trash problem I have replicated on many different computers with different setups ... on 10.3.3 and 10.3.2 - it only affects AD authenticated users that are not in the 'Allow administration by' groups.

TIP: Active Directory and Mac 10.3.3 Server and Clients

May 4, 2004 -- We've posted Greg Priglmeier's paper How to use Active Directory and Macintosh Clients without Schema Changes on another web page. Priglmeier describes the paper:

I have been working on AD integration for several months and I'd like to share a document that I generated for complete Mac authentication and workstation management.

Details: Windows 2003 AD Server, Mac 10.3.3 Server and Client.
Basic AD Authentication for clients.

How to use AD and Open Directory together to manage Mac clients with Workgroup Manager. Single sign features and how to set this up on the OD Server.

Priglmeier is interested in feedback, so if you'd care to comment,

Problem with Active Directory, 10.3.3, and audio CDs.

May 4, 2004
Court Levy reports more weirdness with Mac OS X 10.3.3 and Active directory, this time playing audio CDs:

We have been seeing a problem with the Active Directory plug-in that I have not seen posted before. When we bind to AD in 10.3.3 we can not use audio CDs. When we put in an audio CD we get a message that the Disk is a format that OS X can not read and we are forced to eject it (data CD's work just fine). Local admins get the same message. If we unbind from AD it works again.

We use SMB home directories, but it seems to happen even without this.

If you've seen this problem,

Workaround

May 13, 2004
Jason Simons

We have seen this as well, but you should also notice that Font Book doesn't work! We have actually seen this since 10.3 was released when using the AD plugin. The workaround that I have found is to check the box that caches the last user logon for offline operation. When you log in, there will be a dialog box that asks you to create an account for mobile computer (or something like that). Choose create, and you should be able to use CD's again. We have a bug filed with Apple, but they haven't fixed it yet.

Thursby's ADmitMac 1.1.1 update fixes .local issue.

July 9, 2004
MacWindows reader Gareth Medd reports that Thursby Software's ADmitMac 1.1.1 update fixes a problem with .local domains. Medd confirms that the update works:

Thursby have provided a fix to Active Directory domains named .local. The update can be found on their forum site for ADmitMac; it provides a download of version 1.1.1. It works. Previously it would only recognize as an NT domain now it recognizes as AD.

A link to the update and a description of the problem and solution can be found at Thursby's user forum.

ADmitMac is Mac OS X software that provides Mac client integration with Microsoft Active Directory without schema changes and without the need for Mac OS X Server.

Clearing Mac OS X User Logon Cache for AD.

July 22, 2004
James Hanback is looking for help with single-pass logons to Active Directory:

I discovered recently that single-pass sign ons stopped functioning for my Panther/AD users. Turning off the CACHE USER LOGON option in Directory Access fixed the problem. Alas, if something happens to the network, users won't be able to get to their desktops.

Do you know of any suggestions for automatically clearing the Panther user logon cache at specific intervals to prevent the aforementioned problem from happening again? I assume I could set a cron job to do it. The problem is: I can't seem to find where the cache is stored.

If you can help

OS X 10.3.4 effect on Active Directory integration: -localhome and -mountstyle

July 9, 2004
Jason Meyer suspects that the Mac OS X 10.3.4 update has changed the way a Mac can interact with Active Directory.

Seems like the options -localhome and -mountstyle are no longer available in 10.3.4. When I tried to disable the creation of localhome folder and user their network home folder dsconfigad just spits back the help info.

Also having a weird problem in a test environment, where all users can authenticate to AD just fine, but only a couple get their home folder mounted in the dock. I looked at /var/log/system.log and saw this:

/System/Library/CoreServices/SecurityAgent.app/Contents/MacOS/SecurityAg
ent:
MCXSecurityAgent: Skipping mount of
kDSStdRecordTypeUsers/kDSNAttrOriginalHomeDirectory as "abcdef": Missing

or

badly formed URL

The home folder is on my Win2K server, haven't tried putting it on the OS X server yet, and I have tried both \\servername\share\username and \\server.domain.name\share\username. Still curious as to why, it's not a permissions problem on the server as I can browse to the home folder and drop stuff in it just fine.

August 3, 2004
Dan Cochran

I also have seen the problem discussed by Jason Meyer. Since 10.3.4 I am unable to mount SMB shares as home directories. I can execute the dsadconfig&endash;localhome disable command, but after I authenticate against AD, I get the message that the home directory could not be found.

Something has changed and I'm still baffled.

October 27, 2004
Nicolas Reichelt reports that this may be related to case sensitivity:

I had a similar problem with a customer and found that the patches of the Home directories are case sensitive. I.E. if USERONE has an entry //SERVER1/LOCALHOME/USERONE as the sharepoint in AD, and USERTWO has //server1/localhome/USERTWO as the entry, they cannot share the Homes on the same client Mac. The local mountpath is not deleted after logout of the first user, so the second gets problems.

Solution: all entries in AD should be uppercase (or all lowercase, at least the same case).

If you'd like to comment

Using localhome disable and -mountstyle SMB

A reader asks a question about a logon problem. Answer is given in the article below this, called ExtremeZ-IP and Active Directory

September 15, 2004
Kevin Davidson

I have bound the single iMac here to the AD domain. And I can log in as any user and create a mobile (local) account. I have tried using the -localhome disable and -mountstyle SMB args to dsconfigad but they seem to have no effect (though dsconfigad -show says it worked) as you are still allowed to choose to create a mobile account and logging in with the network home does not work properly.

The system logs show this repeated error:

Sep 10 11:09:47 Adventi-iMac loginwindow[1005]: Failed to stat homedir: sleeping 1 second: chdir returns -1 for /Network/Servers/SERVER/users/USER/: Attempt 8

Sep 10 11:09:48 Adventi-iMac loginwindow[1005]: Failed to stat homedir: sleeping 1 second: chdir returns -1 for /Network/Servers/SERVER/users/USER/: Attempt 9Sep 10 11:09:49 Adventi-iMac loginwindow[1005]: Failed to stat homedir: sleeping 1 second: chdir returns -1 for /Network/Servers/SERVER/users/USER/: Attempt 10

And eventually it gives up and claims it cannot find the user's home, so they end up with / as their home directory. I'm guessing that the way the user home is specified in AD is not laid out quite the way that the Mac wants as I cannot browse to

/Network/Servers/SERVER - it only shows up in /Network/WORKGROUP/SERVER

where WORKGROUP is the left hand part of the AD FQDN. Or that it is trying to mount an AFP home as only the iMac itself shows up in /Network/Servers with its Rendezvous .local name.

(Actual names replaced by WORKGROUP SERVER and USER.)

October 29, 2004
Andrew Cunningham

You asked that if anyone else had seen errors regarding "failure to stat homedir" that they should contact you. I have made an effort to document my woes with this issue here.

And while we have managed to reduce the occurrence of this, we do still see it on a daily basis. I have managed to create a few scripts that allow me to recover from it, but it certainly is a nuisance!

ExtremeZ-IP and Active Directory

September 20, 2004
Geordie Korper, a systems engineer at Group Logic, provided some information about Macs and Active Directory that could apply to a several situation. Korper responded to a reader's problem report at MacWindows last week about trouble with using "localhome disable" and "mountstyle SMB."

Korper points to an Apple Knowledge Base article, describes how ExtremeZ-IP could be used, and mentions that his paper at Group Logic's web site could help readers troubleshoot Active Directory problems:

According to the Apple Knowledge Base Article 107943, "-mountstyle smb" is not supported with "-localhome disable". For more information see

That article states,"In Mac OS X 10.3.3 or later, the Active Directory plug-in supports network homes mounted from an AFP server. SMB homes are not supported." I believe this means that it may sometimes work, but is not reliable.

By the way, you will also need an AFP 3.1 server (such as ExtremeZ-IP) or some of the files will not be able to be saved to the server. For example com.apple.systempreferences.000a95891224.plist is quite a bit longer than the 31 character limit imposed by earlier versions of the Apple File Protocol.

I wrote a guide to Creating Active Directory Integrated Home Directories with our ExtremeZ-IP file server, which is available in the Group Logic knowledge base.

I have a brief section that talks about troubleshooting that may be useful to Mr. Davidson and other people who are trying to make network home folders work.

Geordie Korper
Senior System Engineer
Group Logic, Inc.  

The Group Logic page noted above contains a brief description, with a link to a PDF file containing a longer article.

Problems with Active Directory passwords and OS X Address Book

November 8, 2004
Steve Dockery

I've bound our Mac OS X 10.3.5 Macs to our Active Directory server, so you can log into a machine and it will create a new user for you on the spot. I've been creating mobile users, so they will persist. In some cases, the user was already on the machine before binding. Here's what I've found:

1. If the user is already on the machine, Active Directory does not override the local user's password, even though the exact same (short) user name exists in AD. Perhaps it is because it doesn't match in all particulars. The only was I can get the AD server to do the authentication for a user is if the user was created by logging in as an AD user that did not already have a local user. I believe this behavior is the same in Windows.

2. If a user was created by logging in and set up as a mobile account, they can't alter their OS X Address Book. Any attempt to edit or add an address causes the Address Book to lock up with a spinning beach ball. Local users can edit their Address Books at will. Fixing permissions doesn't solve the problem, neither does giving them local admin privileges.

If I can't solve the Address Book issue, I can't use AD for user authentication, I need people to be able to add contacts to their Address Books.

Suggestion

November 10, 2004
John Sanders

I haven't seen this problem in 10.3.5, but I suspect I know why Steve Dockery is having trouble. In Directory Access, when you bind to Active Directory, you also have to explicitly add AD to the Authorization list and you can also add them to the Contacts list (you absolutely don't have to for the authorization part to work fine). This is basically a list of the places the Mac will search for contact information, or where the Address Book will look when someone is using it. It may be that this part doesn't work so well, or doesn't work in his environment. I would recommend NOT using the Contact part of the equation, particularly if you aren't really using it.

If you've seen this problem

Microsoft KB article useful for AD queries in Mac OS X

February 14, 2005 -- Microsoft Knowledge Base article 238007, How to Configure the Address Book to Query Users Contained in Active Directory, describes using the Windows 2000 address book client to do Active Directory queries. Tony Euser found that some of the information in the article is useful for doing queries with the Mac OS X Address Book:

Open the Address Book.app and select Preferences. Select the LDAP tab and add a new entry. Give it friendly name, and enter the server name (ie. the full DNS name of the domain controller).

Leave the search base empty and use port 3268 (NOT 368) and turn on SSL. Set the scope to subtree and enter your domain credentials (e.g.. domain\username ), password and set the auth type to simple. Hit Save and you're done.

What just blew me away is that not only can I query for users, but for ANY object in AD! Mind you the template in Address Book is for users, so other domain object properties are not revealed

A suggestion for mapping home directories.

February 14, 2005 -- Jason Meyer passed along a tip for getting mapping a home directory in Active Directory:

After a bit a mucking around as to why my OS X client computer would map a home dir for one ActiveDirectory user and not others, I found that you need to make sure the computer account for the client can read all the attribute for the AD user. Just thought I would point this out if some one can't get it working correctly

July 25, 2005
Andy Page
United Kingdom

I have been in contact with Apple ref this issue and we have found the solution by accident.

Our Macs are bound to our Windows 2000 Active Directory. Macs will join the domain fine but the home folder mapping would not work.

We found if the time was too far out on the Server where the home folders were, the Mac client would not map the home folder, yet it would work with OS X 10.3.9.

So be warned a lot of the mapping problems could be down to times being correct on the client and server ours was out by 10 min. My colleague Stuart had seen something like this with a windows PC accessing a file share.

"Enable Workgroup Managment" dialog at login

March 18, 2005
Marc Berger

I work at a Junior College and have become the primary Mac guy in a dominating Windows world...I've got two Active Directory issues:

1) If a user is designated as a local administrator of a Mac workstation (either by being in a group specified in the Active Directory plugin or by being in the managed by tab) then they get a dialog box after logging in and before the Finder appears that says "Enable Workgroup Management?" You must click "continue" if you want your Active Directory home directory to show up. This seems like an annoying step to take every time an administrator user logs in.

March 23, 2005
John Sanders: 

I've seen that too. If you un-check the top box and check the lower one (remember this), the box won't appear again (unless you hold down the option key on login). It shouldn't effect your ability to administer the machine.

March 23, 2005
Jason Meyer

Users with Admin accounts have the option not to have managed prefs pushed down to the machine if they so choose. Call it a "feature."

 

Mac won't sleep with Panther AD plugin

March 18, 2005
Marc Berger

If using the Panther AD plugin, the Mac will not go to sleep when an Active Directory user is logged in. The Mac will sleep at the login window or when a local user is logged in.

March 23, 2005
John Sanders

I haven't seen this, but I would recommend against using Sleep in general use. I've found it causes too much confusion and can mess with some programs (kiosk ones especially). I recommend using the startup and shutdown scheduling instead.

March 23, 2005
Jason Meyer

I can see this as a good thing. If the Mac went to sleep it closes its network connection. When woken up it would have to be logged in again to get a new Kerberos ticket.

Macs bound to AD lose user accounts

March 18, 2005
Steve DeMott

Here's one we have seen 4 times in the month we have been testing binding our (mostly) Mac workplace to Active Directory (Exchange Server):

The user is unable to login using his/her credentials, though they worked even moments ago. This has so far been after a user logout or restart. The user's home directory is still there, but the owner is set to "unknown". In one case we were able to change the owner to the proper user. In the other 3 cases we had 2 scenarios:

[1] The user appears in the owner list, but selecting it (even from root account) causes an error and reverts back to "unknown."

[2] The user is not in the list and the directory must be backed up and then deleted so that the user account can be recreated.

Has anyone else seen this? This is particularly concerning as our parent company is requiring us to bind all Macs to AD to implement new security measures.

March 23, 2005
Jamie Pruden has a suggestion:

I've been seeing this recently at our school. The only common thread I've found is that the user has recently (within 2 weeks) changed passwords on their AD account (we require password changes every 120 days.)

I've been able to fix the problem 100 percent of the time by:

  1. Log in as local administrator.
  2. Unbind machine from AD.
  3. Restart machine.
  4. Log in as local administrator
  5. Rebind machine to AD.
  6. Log out.
  7. Have user log in with their AD credentials.
  8. When presented with the dialog to create a mobile account, do so.

The machine comes back up with all of the user's files intact.

Now if I could just get the machine to update the user's login password with the AD password after AD password changes, I'd die happy...

March 23, 2005
Henrik Boes

Just wanted to confirm the issue Steve DeMott reported and that you posted on 3/18. 

I ran into this with (of all things) our president's Pismo PowerBook, running OS X 10.3.3 or 10.3.5 at the time. (The machine has since been updated to 10.3.8).

NetInfo Manager completely lost track of the account, although the user folder itself was still present, necessitating the recreation of the account and then transferring the data back.

I emailed Apple about this and did not hear anything back. As near as I can tell, this is somehow triggered by repeatedly accessing the AD-integrated account using cached credentials, i.e., when you are not on the network that contains your domain controller. (We ran into this when the prez was out of the office on business.) 

I'm hoping the 10.3.8 update, which, as I recall, included some AD-related fixes, will address this issue. I'm interested in seeing what other folks have ascertained.

If you've seen these problems

Apple 2005-003 Update causes AD binding problem

March 25, 2005
John Skinner reports that Apple Security Update 2005-003 for Mac OS X has cause problems with binding to Active Directory. He also offers a workaround:

I've been using Apple Active Directory plug-in for Directory Services to "bind" a Mac to an Active Directory (AD) computer account ever since 10.3 came out.

It has worked like a charm! Users with an AD user account (in a specified AD group) could log on to a Mac that they never had before, and would have a local account created for them with administrative rights on the Mac! They could connect to network file shares without authenticating for each connection.

Now after the latest 003 update, trying to bind a Mac to an AD computer account stopped working!

It gave me an error at the last stage of the bind saying that the user account didn't have sufficient privileges (referring to the AD user account I supplied) to joint the Mac to the AD computer account.

So, I called up a network administrator to help me troubleshoot it, and here is what we found out.

When you create the computer account in AD, just like always, it inherits the permissions of the OU it was created in. The admin group I am a member of has full permissions on this OU, so the group was added to the computer account with full permissions.

Before the Apple Security Update 2005-003:

The Apple AD plug-in would be fine with this and realize that the AD user account supplied during the bind was in an AD group that had sufficient permission to join the Mac to the AD computer account.

After the Apple Security Update 2005-003:

The Apple AD plug-in will not check to see if the AD user account supplied during the bind is a member of an AD group with sufficient permissions to join a Mac to the AD computer account.

THE FIX:

The way we were able to get around this was to give my AD user account full permissions for the AD computer account I was trying to bind the Mac to.

If you've seen this problem or tried this workaround

March 29, 2005
Eric Sanders

My recent troubles joining a Mac to AD are very similar, but I cannot say which OS X update (or Windows update) seemed to bring about the troubles joining to AD. I have found that using the Kerberos client and getting a ticket in the proper realm seems to be enough for the binding process to complete. My suspicion is the realm in not being defined during the joining since the default realm is blank in the Kerberos tool. The first join attempt to AD failed, next use the Kerberos client to get a ticket from the AD domain, finally join to the AD with success.

March 29, 2005
Jason Broccardo does not see a problem:

Bound to Active Directory (Windows 2003 Server) with Directory Access plug-in (set to prefer a particular server). Mac bound using an account that is a Domain Admin in the AD Domain.

Successfully updated to machines to Mac OS X 10.3.8 and applied the 2005-003 update without breaking the AD bind. Did not have to rebind Mac.

Problem with 10.3.8

April 19, 2005
Michael Balogach

I updated from 10.3.7 to 10.3.8 and now I can not keep the binding. I have no problems binding the Mac to the AD (Windows 2003 Server with SP1), but if I log off and try to log back on It does it shake. I can login as root and re-bind with no problems but it does not keep it. I also tried leaving the Mac logon for hours and then before I would log off I would open the network home folder. Then I logged off and then logged back on with no problems.

Firewall problem with Active Directory, OS X: "unknown error" at step five

A suggested fix is below.

April 11, 2005
David Wood reports a problem with a Mac accessing Active Directory after a firewall went up:

Attempting bind a PowerBook with OS 10.3.8 to a Windows Server 2003. I was able to bind the notebook before the administrator installed a firewall on the Win 2003 server. Now the active directory binding setup hangs on step 5 of 5. After sometime a message stating, "An unknown error occurred."

Earlier today I sat with the server administrator to try and sort out if there was an issue with my connection rights. What we saw was baffling.

The Mac is connecting to and communicating with the server. A computer object is also being created in the directory. The issue appears to be somewhere after computer object creation on server and binding confirmation on the Mac. Are there firewall issues or ports required open that we may not be aware of?

April 19, 2005
Mike Tuller

I have seen this error, but only a couple of times. I have had issues with the AD plugin though. Most every time I try to bind, it comes back that the username and password is incorrect. I don't change anything, and after a few tries, the system will finally bind. A network admin and I looked at this with Etherpeek, and it seems that the AD plugin is asking for a lot of LDAP entities that are not in the AD directory. I've just dealt with it for now, and am hoping that with 10.4 this will be cleaned up.

In short, the error that was described on MacWindows is just one of many problems with the AD plugin.

November 28, 2005
Alvin Bridges

We have been battling this unknown error in binding our Tiger workstations. It has really prominent since the implementation of 10.4.3.

During step 5 of the binding process in the directory access utility you receive the error "unknown error". The machine is not bound at to AD at this point. But if you go through the process one more time right after that. The process goes twice as fast and succeeds. But it is hit or miss if the machine is actually bound completely or not.

The fix

November 28, 2005
Scott Dungan

I have seen this behavior as well and I believe I have a fix.

Microsoft has a Knowledge Base article that discusses exactly which ports to open on a firewall to allow for, among other things, clients to join and authenticate with the domain. After setting up the firewall and the needed ports, all our Windows clients joined to the domain and authenticate fine. Any Mac OS X 10.4 client (we have not tried any down level clients like 10.3 yet) will begin to bind (join) to the domain as the previous reports explain, but it will crash on Step 5 of 5.

After setting up a test environment and a packet sniffer, I noticed that the OS X 10.4 client was requesting kpasswd on UDP port 464. This port was not specified in the Microsoft KB as needing to be open. I opened the port on the firewall and it worked! The 10.4 client bound to the domain and continued to authenticate just fine.

December 6, 2005
Steve Kimberley says the fix works:

I found the same problems as others: OS-X 10.4 client would not connect to a Windows 2003 server which had the firewall up, although it connected OK without the firewall.

Cut to the chase: I found the suggested fix by Scott Dungan (November 28, 2005), tried it and it worked! I now have a firewalled 2003 Server allowing kpasswd through on UDP 464 and no more connection hangups. Thanks, Scott!

June 1, 2006
Sebastian Hagedorn

Opening port 464 UDP saved my day. After reading the entry at MacWindows I opened port 464 UDP in our Cisco ACLs and now I can bind our Macs to AD.

None of the Windows experts here were aware of this port, so it hadn't ever been opened.

If you've tried this fix

May 29, 2007
Corey Baldwin commented on our reported fix for a problem with binding to Active Directory through a firewall.

This is in response to Scott Dungan fix.

What if some computers work and some don’t, and some computers fail the first time and you change the name and then it works, or they fail for a few days and then work with no changes? If some work and some don’t then UDP port 464 has nothing to do with the binding issue.

One thing I’ve found interesting is, at an advertising agency I worked for, they had AD setup with companyname.com and never once had an AD binding problem. Since then I’ve worked at two other companies that had AD setup with companyname.local and have had nothing but problems binding. And yes, I an aware of adding local in the search domain for Tiger and the procedure in Apple Tech Article 107800 for Panther to work with domains setup with .local.

Reader says Firewall problem with AD, Tiger: "unknown error" at step 5; workaround doesn't work

Monday, March 3, 2008

Anthony Fappiano is seeing a previously reported problem with Tiger Mac binding to Active Directory through a firewall. However, the suggested fix isn't working:

The fix regarding UDP 464 doesn't work for me. I still get an unknown error issue after step 5 on the bind. This is with Tiger. It should be noted also that this works fine as soon as I take the firewall out of the equation. The issue seems to be that Tiger cannot set the computer account's password in AD through the firewall. It has no problem setting the password when there is no firewall in place. I've even taken it as far as opening ALL ports and it still fails through the firewall.

We've previously reported a fix for failures at Step 5 in general.

If you have a suggstion

Tiger problems with Active Directory

Win clients locked out of Tiger Server/AD

June 21, 2005
Gavin Walsh has workaround to a problem with Windows clients accessing Mac OS X 10.4 Server. Unfortunately, the workaround needs to be repeated often:

I have a Tiger Server with Windows and Mac clients authenticating their access to it via an Active Directory. Every time I use the Workgroup Manager to change permissions and save it, our Windows computers can no longer access the share points on the server. The work around for this is to comment out "auth methods = guest opendirectory" and restart windows file services. Users can then access their share points on the server.

This is a problem as every time you change a permission on the server via the Workgroup Manager you need to go back in to the smb.conf file and re-comment out the line as the server overwrites it when you save your changes from the workgroup manager and restart windows file services (users then get disconnected from the server).

Is there any way to keep the commented line in the smb.conf file?

If you know an answer let us know.

We have more on this issue on our Mac OS X Server Reports page.

Startup problem with AD and Open Directory

June 21, 2005
Justin Andrews

We're having startup problems with clients that are connected to both Microsoft Active Directory and Mac OS 10.4 Tiger Server Open Directory. If a client is configured to connect to both it has startup problems and won't startup (stays at blue screen with grey loading circle).

I configured 3 computers to connect to the Open Directory only, 3 computers to connect to the Active Directory, and 3 computers connected to both.

The 6 computers connected to only one directory worked and started up fine, the other 3 had random startup problems.

Partial workaround

June 29, 2005
Brad Anderson

I too am having the same issue, I can not bind any Macs running Tiger to AD and OD. I’ve tried 3 separate Macs with clean installs and they all stop while trying to boot. One of them being my PowerBook! To fix the problem, I had to unhook the machine from the network, boot, (they will when not connected to the network) then log into the local administrator’s account and then delete the contents of the /Library/Preferences/DirectoryService folder, then restart. This allowed the machines to boot and use ONLY the local user accounts.

If you've seen this issue let us know.

NOTE: This workaround was verified by a reader who had the problem with Leopard.

Unable to change AD domain password

NOTE: Readers are reporting that the Tiger 10.4.2 Update fixes this problem. (See below.)

June 29, 2005
Matt Sullivan

I'm running a new install of Tiger on my laptop which is bound to our Active Directory. I'm a domain admin and my credentials were not properly set. My account was not set up as an admin account. That's minor compared to my next issue. I seem to be unable to change my password for my domain account.

We have security policies which require us to periodically change our passwords. I am given the warning from the Kerberos Agent that I have so many days before my password expires. That is a nice new feature.

10.4.1 did not fix this problem. I let my domain password expire and was able to log on to my Mac with the old one. I am also unable to change my domain password using the Accounts system preference. This is consistently repeatable. I can change my domain password with the Kerberos utility, however the change is not recognized by my Mac for local log in. The only way I was able to change my AD bound local password was the command line.

July 1, 2005
David Norris

I don't have much to add, other than the same thing happens to me with 10.4.1 and AD. Computer was bound, password expired, changed it on the domain controller and now local computer account only works with original password and it's cache hasn't reflected the current AD password.

July 5, 2005
Tor Olsen

I have recently installed Tiger in my Windows Server 2003 Domain using the AD Util. for testing purpose. When I tried changing the users password I ran into the exact same problem.

I do hope that Apple comes with a fix for AD integration (we do not need to be religious on OS). I also would like Apple to upgrade their AD integration so it can handle signing of communication between server and client, not forcing me to degrade my Domain security. If I were to use AD integration I would consider using some kind of signing of the communication (e.g. IPSEC), to assure not getting into a man-in-the-middle attack.

July 5, 2005
Alan Brent Stephens:

Same issues here. Annoying, but in our case not critical. Hopefully this will be fixed in an upcoming update, but who knows...

July 9, 2005
Ben Skelton

The first time a user logs on to the Active Directory it determines if they are using the right password and creates a mobile account (which works great when they are disconnected). The only issue is that if the password is changed on the network (through a windows box, etc) the passwords become out of sync. The old password is used to log in to the Mac, and the new password is necessary to access any network resources.

There seems to be a large password synchronization issue here.

A workaround

July 9, 2005
Kirk Rheinlander

When last the password expired (Tiger showed no forewarning), I called the help desk, and they gave me the new password. However, I could not get the login screen to accept it.

For some strange reason, when I delete the keychain item for the login, the password entry in the login screen worked. Keychain updated with the new password, and I am good for another 45 days (next password reset cycle)

Readers say 10.4.2 update fixes the problem

July 20, 2005
Matt Sullivan, who first reported the problem said "10.4.2 has resolved this problem for me.

July 20, 2005
Alan Brent Stephens:

At a glance, It seems that 10.4.2 may have fixed this issue as well as the issue with cached mobile log ins.

While VPN'd to the office, I attempted to change the password. Instead of a cryptic error I received an error saying that my password did not adhere to the directory's password policies. As I don't care to change my password I left it at that, but it seems as if its actually reading the directory properly for the password information.

Also, I have been able to log in to the mobile account when not connected to the office network or VPN. Hopefully this will last.

July 20, 2005
Adrian Cooke in the United Kingdom:

I'm been testing 10.4 with our Windows 2000 AD network and I experiencing following problems with mobiles accounts. Most of the problems have been resolved with the latest 10.4.2 update.

However, the update hasn't fixed the problem where my Mac is locking my AD account. This only happens with a mobile account.

Active Directory/Open Directory problems with mobile accounts

May 2, 2005
Santino Rizzo

I'd like to know if anyone using the AD plug-in can reproduce my problems with Tiger.

1. Mobile AD accounts cannot login when disconnected from the network. Major problem for laptop users. Account info is there in NetInfo, and you can do a Terminal login to that account, but no login from Login Window.

2. Open Directory printing does not properly authenticate resulting in NT_STATUS_ACCESS_DENIED. Printer setups using OD though AD work beautifully, but is completely useless if you can't actually print.

Mac OS X 10.4.1 Update doesn't fix the problem

May 18, 2005
Santino Rizzo

The 10.4.1 update has not resolved my problems. AD users cannot login when not attached to the network. In fact Apple has made the problems worse. In 10.4, I could at least open a login shell or su to my AD account in Terminal from a local account. Now that no longer works.

May 18, 2005
Sean Lynch thought 10.4.1 made matters worse, but has a suggestion to fix it:

I get the same "unknown error" during stage 5 of the Bind with Active Directory 1.5.1. The correct computer object is created in our mixed-mode AD with a PDC and multiple BDCs.

I did a fresh load of 10.4.0 on a G3-400MHz and the bind worked OK. A new iMac G5 10.4.0 and 10.4.1 has the problem
Now I've GOT IT!

1. Trash all files in the /Library/Preferences/DirectoryService (then restart).

2. Config SMB to have your domain name (not FQDN) in the workgroup section (PRINTCORP in my case). I also added this to my WINS server.

This is the only combo I tried, maybe just trashing the files would do it. (The G3 Mac still had Workgroup and a blank for WINS.)

May 18, 2005
Don Wolff

I can confirm that creating Mobile User Accounts in Tiger does not correctly cache the users password and will not allow login when disconnected from the AD domain.

This is a huge bummer, and would love to find a fix for it. Apple is saying that the just-released 10.4.1 update is supposed to fix issues with the Active Directory plugin. Does it help in your situation? Not at all. Upgraded first thing this AM and tried to connect with the new install, no go.

Funny thing about all of this, I contact Apple support after my testing and the guy on the phone sounded completely unaware of the issue at all. I suggested that he go and take a look at their discussion boards.

Possible source of the problem: Tiger NTLM password problem

August 8, 2005
Hugh Burt has a a theory about what is causing this problem. (Another reader verifies it below Burt's report.)

Burt's conclusion:

We have found that the machine is sending the right username with the NTLM protocol BUT the wrong password! On Panther machines, we have found that the H drive is mounted by NTLM on the first attempt. So to put it succinctly, here is the bug - Tiger using NTLM, sends the incorrect password but Panther sends it correctly...Tiger is unusable for us.

Here is his entire report:

We had a problem concerning mobile accounts being locked out for no reason. We have now investigated further and believe we know the reason.

First, I would like to describe our setup.

We are an educational institutional on three sites. Staff home folders are kept on one server, say staffhome. We have five domain controllers for the staff domain. Mobile account users are set to be "managed mobile" i.e. mount H drive but local home folders (documents, library, music etc.) made in the Users folder locally on the hard drive. We have a global policy of locking AD accounts following five unsuccessful login attempts. The lockout automatically clears after 3 hours. The staffome server and staff users are on different sites.

We found that members of staff were being locked out for no apparent reason so our system admins investigated, and from the logs of the staffhome server discovered the following:

A user logs in and is authenticated to the staff domain using kerberos. The machine then tries to mount the H drive using a protocol called NTLM which fails three times following which, the machine uses kerberos which succeeds. However, the staffhome server has logged the three failed attempts used by NTLM and informs it's domain controller and the failures are then replicated to the other DCs. Bizarrely, the logs also show that the machine also twice sent the root username as well.

The member of staff then logs out, say for lunch, and then logs in again when the same thing happens, but now the account has three more failed login attempts against it, 6 in all, and the account in now locked out. The user is oblivious to this as they were able to login and the H drive mounted, but if they now log out and login again, they are unable to do so as the account is locked.

Cause

We have found that the machine is sending the right username with the NTLM protocol BUT the wrong password! On Panther machines, we have found that the H drive is mounted by NTLM on the first attempt. So to put it succinctly, here is the bug - Tiger using NTLM, sends the incorrect password but Panther sends it correctly.

Hopefully your "readers" will find our experience useful and perhaps somebody from Apple will also read it because as things stand at the moment, Tiger is unusable for us.

August 15, 2005
Bob Wallis, an Apple Certified Technician and developer, agrees with Burt's assessment:

I can verify Hugh's assessment of the problem. I manage a 40+ network of PowerBooks and desktops that all authenticate to a Win2k domain with over 300 Windows machines. Most Macs are running Panther 10.3.9, with no problems.

The domain admins have set the password lock out at 3 attempts over a 3 hour period. I have upgraded 3 laptop users to Tiger, and their accounts were getting locked out at least once a day. At first, I suspected a Keychain problem, but after disabling the Keychain, the problem still persists.

At the first login after binding these Tiger machines to AD, the home folder would mount. On subsequent logins, the home folder would NOT mount, and the account would become locked. The temporary, yet unacceptable workaround for these three users is to turn off Authentication to AD in Directory Assistance, and since they have already created mobile accounts, they can still log in. They still can access exchange using entourage, and mount SMB shares, they just have to enter their credentials when doing so...I was hoping it would be solved in 10.4.2.

Hugh Burt's assessment is right on the money as far as I can tell.

Tiger Server disappears from AD network. July 5, 2005 -- Paul Wochnick reports a problem where Tiger Server keeping dropping off of an Active Directory network:

We recently installed a new XServe/XRaid with Tiger Server 10.4.1. We have integrated the Tiger Server into our Active Directory. All users who access the tiger server are authenticated through the Active Directory. The authentication works fine for both Mac and Windows users. We are having a problem with the tiger server disappearing from the network when browsing on the windows side.

When a user browses the network on the windows side the Tiger Server doesn't appear. We can map to a share on the tiger server and also type the address within windows explorer \\tigerserver and users can access it. We have the Tiger Server pointing to our WINS server. The record is there so it appears to be working correctly.

When I restart the samba services the Tiger Server will appear when browsing. But after a few hours it will disappear again.

July 9, 2005
Jay Ethridge

We have the exact same experience running a clean install of Mac OS X 10.4 upgrade to 10.4.1. Since most users have mapped drives it doesn't make a big difference, but it's really annoying for administrators.

A Fix:

July 9, 2005
John Holley

Yes, I have seen this problem. Looking deeper we had some time issues which seemed to screw up kerberos and authentication. In the end I unbound the server for 12 hours and rebound it back to the domain. This seemed to fix the problem.

Instructions for Tiger and AD 2003; integrated authentication

August 17, 2005 -- Rob de Cleen sent a detailed procedure for getting integrated authentication and access to shares for Mac OS X 10.4.2. It involves changes to registry on the Windows server.

NOTE: Another reader offers some tweaking of this procedure below.

After banging my head against the wall for a while, this is how I fixed it, and it's really much simpler than most solutions I found would suggest.

TO GET AD INTEGRATED AUTHENTICATION WITH Mac 10.4.2 and Windows AD Server 2003

1. On the Windows 2003 server
=============================

Make a registry change on the Windows 2003 box.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters
The value of RequireSecuritySignature needs to be changed from '1' to '0'.

AD Group Policy
Windows Settings --> Security Settings --> Local Policies --> Security
Options -->
Microsoft Windows Network Client --> Digitally sign communications always
--> disabled
Microsoft Windows Network Server --> Digitally sign communications always
--> disabled

Close all windows.
Start --> Run --> gpupdate
This will refresh the MACHINE and USER Group Policy and apply them
Or you can reboot the server.

Make sure the user's home drives are mapped with FQDN
Example: \\srv.domain.com\username


2. On the MAC
=============

login as a user with root

IMPORTANT: make sure the users from AD do NOT already have local accounts
created on the MAC, it will mess up the mapping later...

- Applications --> Utilities --> Directory Access --> Configure
forest: myforest.com
domain: mydomain.com
computer ID: mac

For mobile users:
Check " Create mobile account at login"
This will create a copy of the users home dir from the 2003 box on the Mac
This option excludes automounting the users homedrive!

For local network users:
Do NOT check "Create mobile account at login", because that option excludes
automounting the user's homedrive!

- Check "use UNC path from AD to derive network home location"
- Network protocol used = SMB

- Default user shell = /bin/bash

- MAPPINGS: no changes

- Prefer this domain controller : enter AD srv
Add AD users for administration on MAC (or AD group)
Format: <AD-DOMAIN>\<user> or <AD-DOMAIN>\<Group>

- Press the Bind button to bind the Mac into AD
Enter AD Domain Admin & AD Domain Admin password to finish

- LDAPv3 --> Configure --> No changes

- SMB/CIFS --> Configure
Make sure workgroup is entered same as AD domain
You can leave WINS server empty

Applications --> Utilities --> Terminal --> sudo -s --> cd /etc
--> pico smb.conf

This should be in it:

server string = Mac
unix charset = UTF-8-MAC
display charset = UTF-8-MAC
dos charset = 437
use spnego = yes
client ntlmv2 auth = no

; ADD THE FOLLOWING LINES
realm = YOURDOMAIN.COM
security = ADS
; END ADDED LINES

os level = 8
defer sharing violations = no
vfs objects = darwin_acls
brlm = yes
workgroup = DOMAIN
; Using the Computer Name to compute the NetBIOS name. Remove this comment
to $
netbios name = MacName
[homes]
comment = User Home Directories

Ctrl+X
Y
Enter

NOTE:
If you want the users home drive to be the networked drive only (i.e. go
without a local homedrive):

Open Terminal --> sudo
dsconfigad -caching disable
dsconfigad -localhome disable
dsconfigad -mountstyle smb

Reboot the Mac.

Next login to your Mac as AD user with simple username + password. You will find the network home drive automounted on your desktop with read/write access.

That's all folks.

As an added bonus, you will find that both Go --> connect to server AND network browsing now work without any problems at all. The real crux of the matter (verified with tests) seems to have been the one small thing no one mentions: There should be NO local account of the same name on the MAC when you want integrated AD authentication.

Hope this helps other people lose less sleep over this than I did.

Further clarifications

August 19, 2005
Santino Rizzo

A few comments on Rob de Cleen's instructions.

The registry change is not necessary if you are going to set the Local Policy as these do the same thing. I should add that if the server is also a Domain Controller, you will have to adjust the Domain Policy as well.

"Digitally sign communications" for Network Client/Server does not need to be disabled entirely. It can (and should) be set to "if client agrees". This allows for more secure connections for the clients that support it.

The workgroup does not have to be the same as the AD Domain. This will vary from place to place, so people should check with their sysadmin to see if in fact they are the same.

AD computer object deleted when unbinding Tiger

August 31, 2005
Jason Stanford has another binding problem with Tiger clients:

At my University, while testing a new disk image to push out to my lab that uses Active Directory for authentication, I noticed that after unbinding, that computer's object was deleted from the Active Directory. It apparently does not occur on our campus Windows clients when they unbind, only the Tiger 10.4.2 clients.

But not home directories, as the AD plug-in does not use port 445, and the other ports are blocked on our file servers.

September 12, 2005
Steven Sroba

I can confirm after several instances that unbinding a Tiger computer deletes the AD computer account, which differs from unbind on Windows 4.x and higher.

September 12, 2005
Aaron Rosenblum says that this is normal behavior:

This is actually the intended behavior of the AD plugin. Unbinding a client from the domain is supposed to remove the computer object. In Windows, it doesn't delete them, but it disables them. If the poster wants to unbind his clients without removing the computer object in AD, he can delete the "ActiveDirectory.plist" in /Library/Preferences/ DirectoryService/. This will leave the computer object intact on the AD side, but the client will no longer be bound.

Tiger 10.4.3 home folders and binding problems

November 11, 2005
James Doty has some insights into problems with Active Directory binding from Tiger:

I've been having issues with Tiger 10.4.3 and Active Directory on a Windows NAS File Server 2003 SP1. I'm able to bind the client computers to our Active Directory domain without issue. Here's where I run into trouble.

If I set up Active Directory on the Tiger client computers to use UNC path from AD to derive network home location and set it to SMB the Tiger users can not log onto the network. If I leave that box unchecked they can, but then have to select the Go menu and connect to the server from there to find their home folder.

Panther 10.3.9 ignores this error and will log the user in, but not give the AD home folder.

Also, on Tiger, if I select SMB in the Directory Access application and select the drop down I do not see our domain listed. But in Panther I do.

I still haven't solved this issue, but it may be what's causing other people here AD connectivity grief.

A fix

November 21, 2005
James Doty

I wrote last week about home folder issues and logging Mac Tiger clients into a Windows Server 2003 Active Directory. I've come upon a fix that works for us.

I did some research and discovered that our Tech Director had turned off NetBIOS on the server we use for home folders. We turned NetBIOS back on for the home folder server and on the Mac clients enabled UNC path from AD to derive network home location and set it to SMB.

So far I've logged on with a teacher account, a student account and an admin account and all were successful.

The Macs will not properly authenticate at logon to a server who's port 139 is not active.

To test this theory I created a dummy account and set it's home folder up on a server we have that did have port 139 active. This worked great and gave me the info I needed to bring to our Tech Director to get permission to turn NetBIOS over TCP/IP turned back on.

Advice for Mac Active Directory binding problems

December 28, 2005
Nick Vrtis describes a problem with Active Directory binding and how he got around the issue:

I ran across your nice list of Active Directory/10.3.3/Bind problems. I was having something similar. I had Macs in remote offices that would work fine. People could authenticate with Active Directory and do their work fine. Then the clocks would drift far enough apart that Kerberos would complain and we would have to fix the clock and hope that get things back working. Sometimes it would. Sometimes we still couldn't get them logged in. What we needed to do was Unbind from Active Directory, then Bind again.

This would work fine with the machines in the local office. But all the ones in the remote office would hang during Step 5 of the bind process. If we unplugged the machines, carried them to the local office, plugged them in, did the bind at the local office, unplug and carry them back to the remote office. Things were fine and everybody was happy (except yours truly who was the guy who did the carting back and forth).

I must have Googled for a couple of days trying to find out what was going on. Tried all the suggestions... Looked at firewall logs (the remote Macs were connected through a VPN/firewall), even installed a firewall in our local office with just about everything turned off. It still worked.

To make a long story short, I finally looked at the complete network trace and noticed that the VPN router was returning an ICMP "The datagram is too big. Packet fragmentation is required but the DF bit in the IP header is set."

Both the router and the Mac had the MTU at 1500. and for the stuff that was headed out over the non-VPN path, that worked fine... but the VPN path could not handle the full 1500 byes (somewhere around 143x it dies). So the router pitched the packet and told the Mac. Unfortunately, the Mac ignored it and just kept trying to resend the packet and waiting for a response. The Active Directory plugin would look like it was hung and about the only thing you could do with it was Force Quit.

I manually configured the Ethernet port to an MTU of 1400, and both the Mac and the VPN were happy campers... FYI.. the Sonic firewall/router/VPN also had a "Ignore Do not fragment" setting that also seemed to fix the problem (not sure what else is going to fall out from that yet).

This might help others figure out why it works "sometimes" or "some places" and not others. Or even why it might depend on the computer name (which I assume would contribute to longer packets).

Can't change AD passwords with 10.4.4.

January 18, 2006
Bruce Carillon reports that updating to Mac OS X 10.4.4 has caused a problem with Active Directory passwords:

This is a show stopper for us! I just updated to 10.4.4 and can no longer change AD passwords. I'm not sure if it's unique to me or a bug in 10.4.4. Up until 10.4.4 all releases of Tiger have allowed the user to change their password in our AD network. All of our Macs are bound to our AD and logins are validated through our domain controller.

Suggested Fix

January 23, 2006
Bruce Carillon found a fix for a problem he reported to us last week regarding being unable to change Active Directory passwords with the Mac OS X 10.4.4 update. The solution:

I had tried "unbinding" and "rebinding" the machine to AD, which didn't work.

The fix is to open Directory Access, click on the Authentication tab, remove the Active Directory Domain, hit Apply, then add back the Active Directory Domain, hit Apply, and now it all works!

This may also fix some other AD anomalies they have popped up after the 10.4.4 upgrade.

If you've seen this problem or can confirm the fix

Spinning beach ball at AD login

January 30, 2006
Plain Rondel is getting the spinning beach ball of death when his Mac clients try to log onto Active Directory:

Description of our problem:

After a Mac client is restarted, when we try to login with a valid AD user, the spinning wheel appears and spins forever. The only way to stop the spinning wheel is to hit the power button and put the system into standby. Once we hit any key and get out of standby, 2 things can happen. Either the login succeeds within a couple of seconds or the login prompt shakes and denies the user. If the login is denied, we can re-login and the login process is successful. Then, we can log any AD user without a problem until the system is restarted. Description of our Set-up:

(A) Windows 2000 server with SP4: DHCP service is provided from this machine to all computers in the school DNS service is provided from this machine Active directory authentication to all the computers in the school (all windows and Mac computers) The network home folders are stored on this machine. The home folder is defined in the AD's user profile such as \\winserver\users\username

(B) Mac OS X Server 10.4.3: Provides preferences to all the Mac clients in the school

(C) 26 Mac OS X 10.4.3 (iMac and eMac) Configuration of Directory Access: AD service enabled and bound with this option: Use UNC path from Active Directory... network protocol to be used: smb

Workaround

February 3, 2006
Henrik Ahlberg in Sweden reports a rough workaround:

We see the exact same problem as Plain Rondel, though it's intermittent. Our setup is similar to his except that we use Windows 2003 Server, and local home folders.

One workaround is to unplug the network cable for a couple of seconds and then "replug." We've also tried (since late last week) with static IP's set on the clients and so far so good.

February 9, 2006
Fabien Hory uses Unix commands in Terminal to work around the problem:

I also have sometimes this problem with 10.3.9 machines (not 10.4) and here is how I resolved it (for a while because it comes back sometimes).

To unlock the Mac : SSH with root from another machine and kill the loginwindow process ("ps -aux | grep login" to find the PID and then "kill -9 this PID").

Login with the local administrator on the Mac and delete the com.apple.LaunchServices.6B.csstore file in the /Library/Caches directory and reboot the Mac.

By “SSH with root from another machine” he means login to the Mac from another computer. Mac Help describes this (search for “SSH” in Mac Help).

If you've tried this fix, or know of another,

| MacWindows home |

Macs hang during startup when added to AD

Note: a reader offered a fix below.

February 19, 2007
Brad Anderson's Macs are freezing during startup on an Active Directory network. He has a temporary workaround, but it's lost upon restart:

All my Macs boot extremely slowly and the progress bar will freeze at boot up for up to 2 or 3 minutes once the Macs are added (bound) to Active Directory.  If I go into the Library>Preference>DirectoryService and delete all the prefs in that folder, then reboot, they boot just fine. If I then re-bind the Mac to AD and do a reboot, it goes back to hanging during the boot process. I’m assuming this is because something in the boot process is timing out, but I’m unable to find what that thing is.

All my Macs are running 10.4.7 or 10.4.8 (both versions have the same issue). I have both Intel and PowerPC Macs as well. It seems to be affecting them all. We are running a Windows 2003 domain.

Suggestions

February 21, 2007
Joe DiMattio:

I have a suggestion for Brad Anderson's issue with his Macs booting slow when connected to AD. The issue might be the AD environment attempting to "push" global policies (i.e. proxy settings, security settings) down to each attached device. The domain controller/policy server, being unable to find the suitable directories on the Mac, could just be waiting for a timeout on the Macs before moving on.

February 21, 2007
Dedrick Allen:

This user may want to verify that they have full forward and reverse DNS working for ALL Active Directory clients, Windows AND Macs. Active Directory requires DNS and most of the Mac networking features such as MCX and Open Directory require full forward and reverse lookup support.

February 27, 2007
Brent Westmoreland refutes the above advice

Active Directory GPO settings are never pushed. they are pulled by client devices that have the Windows libraries, thereby eliminating this possibility entirely. Boot hanging with windows 2003 is more likely an issue either trying to mount home directories or having the windows 2003 Domain Controller Security policy set in it's default state.

See this link for more details.

February 27, 2007
Jamie Thomson also has the problem. He tried some things that didn't solve the problem:

I too have iMacs G5 and PowerPC and MacBooks (OSX 10.4.8) which all experience the slow bootup when bound to TWO Directory Services. When bound to AD it is blazingly fast, when bound to OD it is blazingly fast, but when the two are used in conjunction its horribly slow, some 15 minutes to boot. I suspect it's network related but I can't prove it.

I was told to check that the switch ports had Spanning Tree Protocol enabled, they did not so I got it enabled. I also bumped the iMacs up to 1 GB autonegotiation. This seemed to help but not much.

You should get a laptop and plug it into the same switch as the AD server and check if the problem exists on a port that has STP PortFast or FastStart (depends on the vendor of switch) You will need to work with your network guys to do this.

TIP: Fix the problem by reconfiguring or removing the LDAP plugin

March 5, 2007
Dan Ball found that the problem wasn't with Active Diretory, but with the LDAP version 3 plugin. A reconfiguration fixed the problem:

When we first switched to Tiger at the Mac OS 10.4.6 revision. I thought things were running great in testing until I re-imaged a lab. If I rebooted the lab of roughly 30 machines randomly they would take forever to startup. Each one would hang for roughly 5 minutes or so before showing the login window.

For us the issue wasn't the connection to Active Directory, it was the connection to our OS X (10.4.6) server.

The fix for us was in the LDAPv3 plugin under the "LDAP Mapping" column, I had to set it to "Open Directory Server" instead of the default of "From Server." I switched this setting and haven't had an issue since then.

Other things I have set: for the search path since we moved to 10.4.x I have to have AD first and then OD second in the search paths. When we ran 10.3.x it had to be reversed with OD first and AD second.

Couple of other things: I set a static edu.mit.Kerberos file, I don't let OS X manage it. And the only services I have on in the Directory Access.app are "Active Directory, "LDAPv3", and "SMB/CIFS".

And hopefully everyone has checked DNS dig -x ipaddress.

Everyone is specifically saying AD, but I have seen the issues with Open Directory and not AD, so I just wanted to point this out in case no one caught it.

March 23, 2007
Brad Anderson verified Ball's fix above, except that instead of reconfigurating, Anderson simply removed the setting:

I can confirm that if I remove the LDAPv3 settings from my Macs, then the boot process is MUCH MUCH faster...reduced from minutes to seconds on my really fast Macs. Removing the entry completely (or disabling it by un-checking the check mark on the main Directory Access screen) will make my machines boot faster.

I have not tried to manually set up my edu.mit.Kerberos file as I’m not that comfortable with Kerberos to be editing something like that – but I’ll more research and give it try on one of my test machines.

Does this work for you?

May 18, 2007
Barry McInnes

We had the same problem moving to AD, we left LDAP plugin and configuration in Directory Access configuration. Startup was extremely slow, and the blue progrss bar would just stay at the end, and eventually give a Login screen. We removed the plugin and the LDAP setup from Authentication and Contacts and restarted. Now it boots up very fast.

More AD problems in 10.4.4: "Allow administration by" groups

January 30, 2006
Don Howdeshell

I have a similar problem. In the AD plugin it has a list of groups that is titled "Allow administration by" and we have items like DOMAIN\domain admins. This worked perfectly on 10.4 up till 10.4.4. The fix of removing /Active Directory/All Domains did not work.

It does seem that entering the group's name without the domain fixes that problem.

Suggestion

February 3, 2006
Nick Pitman

I have also found that if you add groups without the domain names the allow admin feature works correctly in 10.4.4. This also worked for one of the earlier revision of 10.4 but I cannot recall which.

If you're seeing this problem .

| MacWindows home |

TIP: fix for Tiger AD binding problem

March 13, 2006
Shawn Post passed along a suggestion for fixing a problem with binding to Active Directory with Tiger:

I ran into a problem with getting Mac OS X 10.4.4 to bind and to keep connection to AD. The problem was I could get AD to work for authentication of the users but would drop connection for SAMBA as in being a member of the domain. After reviewing the situation n AD I deleted the entry and I tried binding the AD plugin and Samba using different names. This fixed the problem and seems to work great. Example:

Also made two DNS entries for both name to point to the same IP so you can use either name.

how this works for you.

Another suggestion for Tiger AD binding problem

May 9, 2007
Thomas Finley responded to a previously report tip for getting around problems with Macs binding to Microsoft Active Directory:

I had a similar problem, but before deleting user accounts, make sure the local machine's clock preferences are set to synch up with your server's clocks. This was preventing me from logging in (and it was hiding my local user directories).

If you've tried this, please how this works for you.

| MacWindows home |

Reader's OS X Server periodically loses AD connection

May 29, 2007
Erik Zimmerman reported a problem with his Mac OS X server, which periodically loses it's connection to Active Directory:

We have one Mac OS X Server 10.4.9 on a Windows 2003 Active Directory. The problem is that every two weeks the server will lose its connection to the Active Directory and fail to authenticate any domain users from either Mac or Windows machines. A quick unbind and rebind of the server to the Active Directory fixes the problem.

I've setup a separate OU in the directory and used group policy to disable machine account passwords and signing requirements to "only if client agrees." The server is not restarting in the middle of the night or anything like that (I know because our backups keep running, using the root user). In the syslog it shows that all of the sudden user authentication fails and it always seems to happen at night.

The server can resolve all hosts on the domain, DNS reports no errors, no Windows clients are having any issues with the domain.

The Mac OS X server is bound to the directory and both Mac and Windows clients access the server. AFP and Windows are the only two services that are being used on the Mac.

May 31, 2007
Jose Richard also sees the problem:

Hi we have exactly the same problem as Erik Zimmerman. It will correct with a bind/unbind. But for us it happens every week.

May 31, 2007
Sochet Ly does as well:

I have the same problem, but with Windows 2000 Server, and it happened once a week.

June 26, 2007
Bob Nance is another reader who reports the problem:

I have the same problem as Mr. Zimmerman. It happens weekly (on Thursday, actually). I have unbound and rebound the Mac Xserve server on Thursday, and it happens the next Thursday. I have unbound and rebound the server on Monday and it happens the next Thursday (3 days later). It doesn't seem to be related to the XSERVE$ username in the domain.

If you’ve seen this problem

Suggestions

May 31, 2007
Robert Brown had suggestions:

I have seen this issue a few times, the first thing is to make sure you have the proper DNS and Search Domain entries. The other issue could be time drift, as the server and the Domain controller get to far apart the binding is affected, so you should specify a time server to rectify this.

If you’ve seen this problem, or tried Brown’s suggestions

A fix

June 26, 2007
Jose Richard sent us a fix to the problem of Mac OS X Server periodically unbinding from Active Directory:

Here's a solution to permanently correct the periodically loses of AD connection. Next time you do an unbind/bind to correct the problem, after the bind step do the following:

- Run dsconfigad -enablesso after binding

- Verify the following options in /etc/smb.conf:

If you’ve tried this

July 11, 2007
Bob Nance has verified a previously reported fix for Mac OS X Server periodically unbinding from Active Directory:

As reported, this problem has beens solved with the command:

dsconfigad -enableSSO

It appears that the problem was that the Kerberos ticket getting ticket was not being renewed without the additional command. Now, it all works as it's supposed to.

If you can shed further light

More news on the MacWindows home page.

Clarification on fix for OS X Server unbinding from AD

July 30, 2007
Sochet Ly previously reported the problem of Mac OS X Server periodically unbinding from Active Directory. Ly had success with the suggested fix from June 26, but makes a note about its implementation:

I first tried the suggestion, but not straight after rebinding it to AD: that doesn't seem to work. Now I just unbind and rebind to AD, then ran dsconfigad -enableSSO.

After nearly 3 week without have to rebind to AD, I am happy to report that running dsconfigad -enableSSO command straight after rebinding to AD did the trick. So the key thing for me is ran dsconfigad -enableSSO straight after rebinding OD-AD.

More news on the MacWindows home page.

One more fix: delete corrupted prefs file

July 18, 2007
Erik Zimmerman suggested another way to fix Mac the problem of OS X Server periodically losing an Active Directory connection. Eric was the first of several; readers who reported this problem. His suggestion was to delete a corrupted preferences file, which also fixed some other problems:

What finally seemed to fix this problem for me was deleting the preference file for Active Directory. An Apple Tech I talked to recommended this and said that the plist file can become corrupt if the domain is changed in anyway (either name change or AD level, ex 2000 or 2003). Our's was upgraded from 2003 Mixed to AD2003 in December...exactly when this problem started happening.

1.) Unbind the Mac Server from domain
2.) Delete the following file

/Library/Preferences/DirectoryServices/ActiveDirectory.plist

3.) Rebind the computer to the domain

The preference file is recreated with the correct settings.

Our server's been up and running for 3 weeks now and the users say that other minor problems (not being able to disconnect from mapped drives) have been fixed too.

If you’ve tried this fix

More news on the MacWindows home page.

Active Directory-bound Mac corrupting user account, beach ball, only desktop appears

June 28, 2007

Mike Norval reports a problem where a Mac user gets a spinning beach ball when logging into Active Directory, which causes the user account to corrupt:

We have had issues where a user account when you log-on to an Active Directory-bound Mac (10.4.9) after the log-in window all that appears is the desktop background and the spinning ball, sometimes the Spotlight icon appears in the upper right corner and nothing else. It can set I guess all day nothing.

The big issue is you can't restore that user to that machine, if I back-up the account files and delete the user, recreating the user account I get the same thing. Currently I have user that I created a local account and moved her files into it so she could work but have not been able to get back her AD account.

If you've seen this problem

Fix: Corrupted Mac cache is the cause of AD corrupted user account

July 2, 2007

Several readers report that one or more corrupted cache files in Mac OS X can cause the problem we reported last week of a spinning beach ball when logging into Active Directory, which causes the user account to corrupt.

Jason Westlake said the culprit was a bad the font cache file:

Generally, when only the Spotlight icon is showing up as mentioned in this post:

"after the log-in window all that appears is the desktop background and the spinning ball, sometimes the Spotlight icon appears in the upper right corner and nothing else"

it's due to a corrupt font cache in the system. Unless that's deleted, it'll happen to that user again and again, because it's based on User ID number. To fix this, the easiest way is to log in as another user (or Single User Mode), become root, and delete the /Library/Caches/com.apple.ATS directory. Reboot and all should be well. Unless this is an entirely different issue, every time I've seen this, I've been able to fix it by deleting that directory.

Bryan Schappel agreed that the cause was a cache file in this same cache directory, but didn’t identify which one. He also saw this with Open Directory:

I don't bind to Active Directory but I've seen this with Open Directory. In my experience it's not the account that is corrupt but one of the cache files in /Library/Caches. All that needs to be done is to delete the cache files. Log into any other account and delete the contents of /Library/Caches and reboot. The user can then login. I've had 100% success with this procedure.
Mario Ruggiero agreed that the cause was a cache file, but in a different cache folder:
I had the same issue last week, the fault is with the cache files at /System/Library/Caches/ delete the contents of this folder then re-start the mac should fix it. I would also recommend creating a new account from fresh on the Mac in question, and when copying back the data don’t copy back any prefs is possible.

Another suggestion for corrupting AD accounts

July 25, 2007

John Klimeck thinks corrupt Mac preferences files are the cause of the problem with spinning beach ball when logging into Active Directory, which causes the user account to corrupt. Other readers have previously blamed corrupt cache files in several other locations. Klimeck reported:

I have seen this problem with Active Directory 2000 or 2003, where the Mac user sees just the desktop background with a spinning beach ball, etc.

Try to log into AD from a different AD bound Mac, or a re-imaged or newly imaged Mac. Have the user log in from a Windows box, with the AD username and password correct/valid. What this will prove is that some preference (or the OS X image) on this particular Mac that is messed up.

I have never had to re-image in order to regain logging into AD with any particular user’s AD login. Trashing prefs usually works, but in some cases perhaps are-image will be necessary, hence the test from a newly imaged Mac, where AD works.

There are preferences in /Library/DirectoryService, I just trash all these files, as well as any directory service-related prefs in the actual Users preferences.

The acid test is getting a known working Mac or newly imaged Mac, bind it to AD, then see if it will log in properly, it definitely should.

I have seen some funkiness, where the container (AD computer object) is all of the sudden no longer in AD), the container does not exist, somehow it gets wiped away, and have to re-create it.

If you’ve tried this, or one of the other suggestions above,

More news on the MacWindows home page.

AD Groups on Mac not showing on PC Properties

July 30, 2007
Bob Nance has an issue with Active Directory GUID names for Macs:

I have a Mac OS X Server (10.4.9) connected to AD on a Windows 2003 Server. Files were copied from the PC to the Mac using ditto. Security descriptors copied correctly and AD usernames show up in the ACEs on each file or folder while running Workgroup Manager on the Mac.

PCs connecting to the Mac-shared files, however, see the GUID number and no name map. (101660-238940283904-512, for instance, instead of "Administrator")

Windows administrators can set the permissions from the desktop of the PC on the Mac server share, but after hitting "Ok" and then re- opening the Properties window (and checking the Security tab) the name that was just applied is also just a number.

It appears that the Mac is not handing back a number that the Windows computer recognizes, so the PC cannot show a name.

The Admins want to be able to edit permissions from their Windows machines or from WGM.

Logically, it seems like it should work. I think it's related to the "random GUID" for the AD groups. The tool provides a way to set the GUID, but it caused problems for me when I set it.

If you can shed some light

More news on the MacWindows home page.

Old Macromedia software may have problems with Active Directory

August 10, 2007
James Boyle reports an Active Directory issue with Macromedia (now Adobe) Director and ADmitMac (Thursby Software):

Wonder if you've seen any problems in reliably mapping users home directories (using latest rev of ADmitMac) on OSX 10.4.8 (PowerPC > Emacs) to a Windows 2003 file server (running AD). While it seems to work most time, some apps such as MM Director seem to get temperamental about seeing the network home drive. If you create a local user Director runs fine, but it complains if the home share is on the remote windows server.

We asked Thursby Software about the issue, and they pointed to a bug in the Adobe software. A spokesperson said upgrading the Adobe software fixes the problem:

We used to have reports of problems with the way certain Adobe and Macromedia apps dealt with network accounts, specifically when saving files directly to network volumes. After a lot of research, it was determined that the problem was with the way the Adobe applications handled temporary files, requiring local admin access if the user's home folder was not located in "/Users/". Adobe resolved the issue with updates to their entire CS Suite, and we have had no reports of this type of problem since.

More news on the MacWindows home page.

Mac Kerberos Authentication on Virtual Win 2003 Servers

August 29, 2007
Miguel Chan sent us a link that he used to get his Macs to authenticate to VMware virtual servers:

We were having problems with our Mac OS X 10.4 machines connecting to all of our VMware ESX virtual servers running Windows 2003. The Kerberos token would not work. We had to destroy the token then authenticate via NTLM.

We then used information we found at MacOSXHints.com.

And all works now. We did the adjustments on all of our ESX based servers and all is working now. Thought others may benefit from this.

Current news on the MacWindows home page.


UID/GID problem with Mac OS X, AD, and Services for Unix

September 24, 2007
Peter Kloss has a problem with Macs, Active Directory, and Services for Unix and the user identification (UID) and group identification (GID):

I'm having problems trying to use Microsoft Services for Unix (SFU) assigned UID / GID and Mac OS X native AD plug-in. SFU components installed on a DC to allow assignment of UID and GID to 'msSFU30UidNumber' and 'msSFU30GidNumber'. The Mac OS X Native AD plugin is set to read these attributes in the Directory Access utility, AD plug-in Advanced Options mappings. Authentication works fine, as the file system for new a user is created with correct attributes, but file system never mounts. It's left stuck with a blank blue screen and the only way out is a hard reset. Logs indicate that memberd has crashed. Unchecking the mappings option and log-in followed by file system mount is very fast, the UID/GID set is remembered.

Another report of UID/GID problem with AD and Services for Unix

Monday, October 1, 2007

Steve Meyers reports having the previously reported Active Directory problem with user identification (UID) and group identification (GID) on Mac OS X, and Services for Unix:

I'm having the same problem. I have UID mapped to uidNumber, and GID mapped to gidNumber. I've found that memberd doesn't crash if I don't have groups mapped (I still need to have the primary group ID mapped). I'm not mounting any file systems on login, so that isn't relevant; I'm just using a home directory in Users at login.

If you've seen this problem

TIP: Suggestion for SFU and Mac OS X native AD integration

Friday, October 5, 2007

Dedrick Allen responded with a suggestion to previous reports of Active Directory problems with the user identification (UID) and group identification (GID) using Services for Unix (SFU):

I have seen the problem Mr. Peter Kloss describes. I use SFU for OS X integration as it works better than OS X's native support. However, if you do this you have to make sure all the windows groups that your users could possibly be a member of has an NIS Domain and GID assigned on the UNIX Attributes tab of the groups properties.

Please if this works for you.

SFU and Mac OS X and AD integration, and Map Group GID

Thursday, October 11, 2007

Peter Kloss has further insight in to UID/GID problem with Services for Unix, Mac OS X, and Active Directory. He also shared how he got around a problem with the "Map Group GID to attribute" option:

Many thanks for posting my question and for posting the hints by Steve Meyers and Dedrick Allen. By combining the logic in their answers I have now got a working login that meets my requirements.

What I hadn't realized was that I need not tick all three UID / GID mapping options. I had assumed it was all or nothing, and just unchecking the "Map Group GID to attribute" option (and leaving the others ticked) allows the local home to mount and my blue screen problem has gone.

Another issue in our environment prevented us from using the "Map Group GID to attribute" option. We have a hierarchical root and child domain AD, and we make extensive use of universal security groups, which contain members from many of our child domains. SFU didn't understand this, and complained if we tried to set the GID of a group that contains members outside your local NIS domain.

After more testing with SFU and my Mac I got everything working. I should have realized at the outset that using an existing account (my own) in our cloned VM-ized AD environment was a bad idea. Our AD has an "empty" or null root domain with many children that hold the child accounts. Due to sizing limitations our virtualized clone test lab only has 3 out of 10 child domains present. I am the member of 28 windows groups, many of which have members outside our own child domain, and many of which are from domains not actually present in the VM'd clone. I also discovered I am a member of a universal group homed in another child domain which also happens not to be present in the clone! Any process that tries to evaluate the groups in this AD forest is going to have problems. (This clone works very well for a wide range of tests that we have been doing on recoverability and future upgrades to AD).

Using a 'scratch' account which only belongs to two groups in the local domain I was able to log in and mount a local home with the Map Group GID to attribute' option set and when creating a local file I was able to 'get info' and read the GIDs of all the reachable groups in AD, and those which had assigned GIDs showed them. Groups without assigned GIDS just showed '-2'.

So it looks like the failure of my own account was due to the complexity of its group memberships, the unreachability of the referenced domains and the inability of the AD plug in to handle all that elegantly. So there are obviously limitations to this feature that people need to be aware of in complex AD setups.

We have also found a way to assign the same NIS domain name to several child domains so it is possible to assign GIDs to universal groups with the correct configuration.

Current news on the MacWindows home page


TIP: Win 2003 settings to help Mac AD binding

Monday, October 1, 2007

Lorenzo Buresta in Italy had problems binding Macs to Active Directory when he upgraded his server to Windows 2003. Some configuration changes fixed the problem:

I had no problems when I was running the AD domain on a Windows 2000 Server. Binding OS X clients was straightforward. Some months ago we upgraded to Win 2003 and problems began to pop up.

When I tried to bind an OS X client to our AD domain using the Directory Access panel, the AD Forest field could not be changed and showed the same gray writing: -Automatic- Trying to bind only filling the other fields (domain) didn't work, resulting in a "Invalid Domain" warning" "An invalid Domain and Forest combination was specified. You should enter a fully qualified DNS name for the domain and forest."

Our AD domain server is a 2003 SP2 server. The domain name entered is valid, so is the domain administrator name and password. The Forest name is the same as the domain name. Server and clients belong to the same network. DNS servers of client/server are the same. Clocks are synchronized.

I succeeded in binding my OS X 10.4 clients to the AD domain using suggestions from a Discussion Thread in the Apple Support Site.

It seems that Windows Server 2003 is more 'touchy' than Windows 2000 Server as to some parameters I did not used to consider before.

I checked that DNS entry of the Clients is the same of the Win2003/AD server. At the same time, when filling the fields in the Directory Access AD plugin, I managed to specify an AD DC and its IP number (instead of typing its FQD name, as I used to do with the old Win2000).

If you've seen this problem

Current news on the MacWindows home page


TIP: Binding OS X 10.4 to AD when it fails at Step 5

Wednesday, October 17, 2007

Rich Hinds sent in two suggestions for binding Mac OS X to Active Directory. The failure occurred at Step 5 in our tutorial How to use Active Directory and Macintosh Clients without Schema Changes. Hinds describes the problem and the fixes...

Read rest of story here

Current news on the MacWindows home page


Readera can no long bind to AD after Leopard update

This discussion of Active Directory problems in Mac OS X 10.5 Leopard continues on our Leopard Active Directory Tips page.


Reader has AD admin rights problem in Tiger, but not Leopard

Monday, March 3, 2008

James Minerve in London has an Active Directory problem on all of his Macs running Tiger, but does not see it with Leopard:

We have Tiger running on Mac G5's and a few Macs Minis and whilst we can bind them all successfully onto our Windows Domain, there seems to be a consistent problem with every single one of the Macs. We have specified for Domain Users to have local admin rights when going through the binding process; this seems to be ignored and all domain users still do not have local admin rights. (Our users are web designers and need admin rights!) When we go into System Preferences/Users, the domain user does not have a tick to enable admin access; however we can change this manually. Having said this, we installed Leopard and binding along with domain users admin access worked perfectly.

If you've seen this problem


Reader’s AD login gives access to all users

Sunday, April 14, 2008

Scott Firkins has a problem where AD wildcard login gives access to all users in the domain:

We have an issue with Tiger authenticating to AD. Authentication is working great, but we have found quite a security risk. We have the login windows on our Macs set to display user and password fields. If a user enters an asterisk "*" (wildcard) in the username field, all AD users within the domain are listed and you can simply select a user from the list.

If you know of a way to fix this or have seen the problem


Entourage disconnecting from Exchange Server 2007 with Open Directory

Tuesday, October 28, 2008

Steve Searson asked for advice on configuring Open Directory so that Entourage clients can connect with Exchange on Active Directory:

I have an issue with our Exchange Server 2007. We are all Mac clients with OS X Server 10.4 running the DHCP and DNS. Occasionally our Entourage clients get disconnected from the Exchange server. We are on Open Directory OSX 10.4 with Entourage 2004 and 2008 clients. Basically my question is; what is the best way for Open Directory clients to "see" the Active Directory server. Currently what I've done is created a DNS zone in Open Directory so that ad.example.com = internal IP address. This seems to work okay, but I'd like to know if there is a more solid solution.

If you have some advice to share

Reader advice on OS X Server, Open Directory, Active Directory

Thursday, October 30, 2008

John responded to Tuesday's reader report about Entourage clients getting disconnected from Exchange Server on Active Directory with a Mac server set up with Open Directory. John recommends:

Binding OD to AD in my experience is just not that good (especially on the client side), Or should I say Apple (Mac OS X) OD in the AD world, with the Apple AD plugin is not that good or fun.

People can eventually not log in via their AD passwords, whether it's Kerberos or something else where Apple and MS are not jiving.

Not surprising, don't forget MS's technologies are not open to Apple, so Apple has to reverse engineer AD to work in and with OD, and IMHO, OD in AD is a disaster from Apple's standpoint.

From a QA standpoint it just doesn't work, or work well, on OS X updates it breaks all the time, Apple does not quite fix it. I for one am never dependent on OD within AD. Just use local Mac OS X accounts, until Apple and MS fixes it, if they are both serious about it, I for one don't think Apple gives a hoot here , but we will see.

I digress but, as of Exchange 2007 and Snow Leopard at least Mail, iCal and Address Book, with MS's Exchange Web Services this will change how Mac OS X connects with Exchange, whether or not this addresses or improves OD with AD, remains to be seen.

I am pretty sure that in order to run Exchange you have to have an AD Windows 2003 Server, and also running AD, DNS and DHCP on Windows 2003 Server or newer, not a Mac, or Unix box, could be wrong.

Having the Mac OS X Server as your only (main) DNS, DHCP server, not sure this is going to work or a good idea, now Exchange is dependent on a Mac OS X DNS, DHCP server, I have no idea that will work.

DNS is DNS and DHCP is DHCP, but we are talking Apple and MS here.

Enter all the Exchange info into Entourage in Accounts area, and I would put in the FQDN, unless you have the Domain in the Search Domain on your Mac OS X systems in System Preferences.

If you'd like to share your thoughts on this issue

New Apple doc on how to Modify the AD schema for Mac access

Friday, June 18, 2010

Apple has a new (or updated) how-to white paper called Modifying the Active Directory Schema to Support Mac Systems, dated May 2010. Modifying the schema is one of three basic ways of adding Macs to an Active Directory network is to modify the schema on the server. (The other two are to install a Mac OS X Server, or to use a third-party product, such as Thursby Software's DAVE, Centrify's DirectControl, or Likewise Software's Likewise.)

Although many system admins don't like the idea of modifying the schema, the paper provides step-by-step instructions to do so, which Apple calls "extending the AD schema to manage Mac systems.?

What do you think? Is this a good idea? Post your opinion in the MacWindows Active Directory forums.

Snow Leopard Server for Dummies
By John Rizzo

A 432-page book that simplifies the installation, configuration, and management of Apple's Mac OS X 10.6 Server software. Support Mac and Windows clients for file sharing, email, and directory services; Incorporate a Mac subnet into a Windows Active Directory domain, manage Mac and Windows clients, and configure security options, and more. Click here for more.


| Top of This Page |

Other MacWindows Departments

| Product Solutions | Reports: Problem and Fixes | News Archives | Site Map |
|
MacWindows Home |

This site created and maintained by
Copyright 2003-2010 John Rizzo. All rights reserved.