 |
 |
 |
 |
 |
|
|
|
|
|
|
Last updated October 24, 2008
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:
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.
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.
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.
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.
(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:
- Open the Terminal Application
- Type the following (Must have root privilege or sudo account): sudo pico /etc/resolver/local
- You will see three lines in the file: nameserver ipaddress, port 5353, timeout 1
- On the nameserver line, replace the current IP address with the address of your local DNS server: for example nameserver 10.0.0.1
- On the port line, replace 5353 with 53.
- 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:
- Authentication (it seems to be okay)
- Having a UniqueID (it can be solved by mapping another unique value)
- 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 machineJust 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?
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
vplogonUpon 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.
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.
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.
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:
Finally, I think that Network browsing is still unreliable especially with large networks. I have had it working but after the latest security updates it doesn't always work.
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.
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!
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,
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,
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.
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-aAaaBut 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
$ exitThese 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.
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.
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
David is apparently mistaking his local admin privileges on his laptopfor 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.
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 confi