Snow Leopard and Active Directory Tips and Reports

Working with Snow Leopard and Microsoft Active Directory

Updated November 23, 2011
On This Page:

If you’re using Snow Leopard about any problems or tips.

 

iPhone and Exchange Server Tips and Reports

Windows Servers and Macs


Windows on Mac

- Virtual PC 7.x
(PowerPC Macs


GoToMeeting - Online Meetings Made Easy

Tips and Reports

Reader reports Snow Leopard disabled AD single sign-on | Top of Page |

Wednesday, September 2, 2009

Henrik Boes reports that upgrade to Snow Leopard disabled Active Directory single sign-on:

My MacBook Pro was running Leopard 10.5.8 and authenticating to an Active Directory domain (Windows 2000 Server). I upgraded to Snow Leopard and have lost all Single sign-on functionality. Looks like (based on what the Win2K Server logs say) that the machine account and the user account I use are trying to sign in as GUEST, which has been disabled in AD. At this point, I'm looking at completely redoing my AD binding and setting up the mobile account again. Not fun.

If you've seen this problem

Snow Leopard AD problems linked to Mobile accounts; link to workaround

Wednesday, September 9, 2009

Readers responded to our previous report about Snow Leopard disabling Active Directory single sign-on. Two readers report that the new operating system has problems with mobile accounts.

André Sanchez has the problem and located a workaround:

We're testing Snow Leopard and have found that when we bind to Active Directory using the Apple Directory plugin we are not able to log in if we have the "Create mobile account at login" enabled - all we get is the "shaking" login screen when we input valid credentials.

There is a thread about this on the Apple support forums with a workaround for the problem, but I'm hoping Apple will address it with a 10.6 update soon. Topic : Unable to login @ login window with Active Directory User

Joseph Swenson also located a workaround:

My MacBook Pro was running Leopard 10.5.8 and authenticating to an Active Directory domain (Windows 2000 Server). I upgraded to Snow Leopard and have lost all Single sign-on functionality. Looks like (based on what the Win2K Server logs say) that the machine account and the user account I use are trying to sign in as GUEST, which has been disabled in AD. At this point, I'm looking at completely redoing my AD binding and setting up the mobile account again. Not fun.”

SMB shares served via clustered servers won't connect using kerberos. This bug appeared waaaaay back in 10.5, and was reported in early builds of 10.6. Connecting to shares on single-machine servers works fine.

Mobile AD accounts are very much broken. This thread on Apple's discussion boards has a workaround:

Henrik Boes updated his previous report:

I was the one who first contacted you regarding this. Just thought I'd follow up.

I was NOT able to rebind to the AD domain. Period. Kept getting an error saying that I was not entering a fully qualified domain name. No errors in the Windows server logs that I could find. That was that. (I had used the very same settings to successfully bind several machines running 10.5 to AD, so this is not a user error issue.) So no AD integration for us at all under Snow Leopard.

If you've seen this issue

File sharing fix doesn't address AD automount problem

Friday, September 18, 2009

Michael Oman-Reagan reports that the workaround for Snow Leopard logging on to Windows servers doesn't fix the Snow Leopard's problems with Active Directory:

We've been experiencing the same problems accessing shares on a Windows server via SMB. We can access them without a problem from 10.5.8, but 10.6 didn't work.

We found that we can manually mount the share with domain\username as the login name, where this was unnecessary in 10.5.8. But this doesn't solve the problem of auto-mounting these shares through the AD plug-in.

More on Snow Leopard Active Directory woes: Invalid username

Friday, September 11, 2009

Marcus Walker responded to our reports of Snow Leopard not being able to connect to Active Directory:

I've seen the issue as well with all of the systems that we "upgrade" to Snow Leopard. Systems that previously enjoyed binding to the AD and single sign-on, lose that and cannot bind to AD.

We have the same issue with new systems as well. After creating the account in AD (we get nowhere if we don't do that) we get asked if we want to join the existing account. Then we put in our account and password on the domain and receive this error: Invalid username and password combination ...

It doesn't matter how we enter the username (just username, domain\username, domain/username, username@domain, and all the previous with FQDN) we get the same error.

If you've seen this issue

Reader gets "invalid username" when creating Mac AD account

Friday, April 8, 2011

Will Bailey reports having the problem in which an "Invalid username and password combination" error follows an attempt to create and Active Directory account for Macs:

I've just been researching an error we've been having with our AD integration and I saw that you wanted to hear from people who_ve had similar woes. I'm referring to this post More on Snow Leopard Active Directory woes: Invalid username. We potentially have the issue but it occurs randomly on machines that work fine for months then spontaneously lose authentication. Unbinding/Rebinding is impossible. Deleting directory plists doesn't fix it but reimaging machines does.

If you've seen this problem (Update: Scroll down for a suggested workaround to this problem.)

TIP: Fix for "invalid username" when creating Mac AD account

Tuesday, April 13, 2011

Joe Garfoot in England sent us a workaround for the problem of getting an "Invalid username and password combination" error with Macs and Active Directory:

I've seen the problem where some machines will not bind to AD with the "invalid username" error message. Nothing done in the GUI can make it work. These machines had previously been bound to AD. The workaround I found was to delete:

/private/var/db/dslocal/nodes/Default/config/Kerberos:REALM.NAME.plist
(REALM.NAME will be different)

Restart Directory Service:
sudo killall DirectoryService

The Mac will then rebind with no problem.

If you've tried this fix

Reader adds step for fixing "invalid username" in Mac AD accounts

Monday, May 9, 2011

Chris Ellis added a step to the tip "Fix for invalid username when creating Mac AD account:"

This works for me. Only detail missing is that you need to enable the root account and login as root user.

If you've tried this suggestion

Reader confirms fix for "invalid username" AD problem

Wednesday, June 1, 2011

Amos Deane in London confirmed the tip "Fix for 'invalid username' when creating Mac AD account:"

Joe Garfoot's fix worked for me with a problem we've had rebinding an iMac 2007 that had dropped off AD.

If this works for you


TIP: Apple advice for SMB connections in Win 2008 Server AD environment | Top of Page |

Tuesday, September 22, 2009

Apple tech support article TS2967 reports a problem where Macs can't authenticate to SMB shares on a Mac OS X Server. The problem occurs if the Mac OS X Server is bound to Active Directory containing Windows Server 2008 domain controllers AND when the Mac clients are not bound to Active Directory. This occurs with Mac OS X 10.4, 10.5, and 10.6 client and server. Apple offers two fixes:

  • Bind the clients to Active Directory; or
  • Enable "Allow cryptography algorithms compatible with Windows NT 4.0" on the Windows Server 2008 domain controller, as described in Microsoft KnowledgeBase article 942564.

(Thanks to Luis Antezana for the tip.)


TIP: Apple workaround for Snow Leopard AD login, mobile problems | Top of Page |

Wednesday, September 30, 2009

Apple has posted a support article called Mac OS X v10.6: Active Directory user may not be able to log in, which offers a workaround to problems that MacWindows have been reporting. Luis Antezana told us about the article:

Here's one more good Apple KnowledgeBase entry from the other day. This helps with AD users who have an AD Home directory specified in the Directory Utility and have accounts set to create a mobile Home directory.

Here is what article TS3019 says:

Symptoms

An Active Directory user may not be able to log in to Mac OS X v10.6 client. This can happen when the Active Directory connector in Directory Utility is configured to "Create mobile account at login," and a Home folder is specified in Active Directory for the user.

As a workaround:

  1. Remove the Home folder path specified in Active Directory for the user.
  2. Log in to the Mac OS X v10.6 client.
  3. Create the mobile account when prompted.
  4. Specify the home folder path in Active Directory for the user.

The user should now be able to log in to the Mac OS X v10.6 client.

If you've tried this workaround

Reader reports success with workaround for Snow Leopard Active Directory login problems

Monday, April 25, 2011

Jarler Martinez reported success with the procedure described in the article " TIP: Apple workaround for Snow Leopard AD login, mobile problems," but finds it tedious:

I followed your this Tip date September 30, 2009 and it worked great. My question is, has Apple resolve this issue yet? We have a large number of Mac users we are having to do this for everyone of them.

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

TIP: For Snow Leopard AD login issues, use upper case domain

Thursday, January 14, 2010

Dave Sherer found that using and upper-case domain cleared up Active Directory login problems he was having:

I have been battling this problem and I found a solution for me that is not a work around and it is something so minor that some people may not have even tried/noticed/or known about it. After checking the Active Directory security log I saw that when I tried to login from the 10.6.2 I was getting event ID 675.

I have found a suggestion at this site. The first Comment by Tero Hikkenen says to make sure that your domain is in upper case. I was using wweducation.edu and there was no login. When I switched it to WWEDUCATION.EDU I was able to login user authentication to AD.

I still had a network folder option. Researching some more found a reference to make sure that your profile path in AD is set like this:

\\servername.domain.suffix\<pathtofolder>\folder <file:///\\servername.domain.suffix\%3cpathtofolder%3e\folder>

When I did that I had the user's network folder on the Dock. I did make sure that I used upper case on the domain.suffix, even though that may not matter.

If you've seen this behavior

Explanation for uppercase domain fixes in Active Directory

Thursday, January 21, 2010

Chris Nowak responded to our report TIP: For Snow Leopard AD login issues, use upper case domain regarding solving Active Domain login issues by using uppercase domain. Nowak has an explanation:

For the folks for whom uppercasing the domain works, I bet they're using Kerberos for authentication. When you setup realms manually for kerberos you keep the realm name all uppercase. You can see the relationship documented in this Microsoft Knowledgebase article.


Snow Leopard AD binding problems linked to DNS bugs | Top of Page |

Tuesday, September 22, 2009

Henrik Boes found some information that links Snow Leopard problems binding to Active Directory to bugs in the 10.6 opearting system. In a follow-up to his two previous reports, he said the DNS info enabled him to bind, though single sign-on still doesn't work:

I was finally able to bind my Mac to AD (Windows 2000 Server). I attribute my prior inability to do so to known DNS bugs with Snow Leopard, described in the following posts at Mac-forums.com and at Apple's Discussions forums.

My fix, per suggestions mentioned in the forums, was to remove all external DNS servers in the DHCP scope that was dishing out TCP/IP configuration on our network. Now the only DNS server I use is the Active Directory controller, for better or for worse.

That said, Single sign-on is still dead, even in 10.6.1. The logs seem to indicate some sort of authentication problem. And, Windows Server logs show that when I try to open a share point on the server, I am doing so as GUEST.

What I don't understand is why authentication would work at least once -- the first time I logged on to the AD-administered account, my Mac must have talked to the server -- and then simply fail, time and again.

If you see a connection between DNS and Snow Leopard's Active Directory issues

TIP: DNS TTL setting may cause Snow Leopard AD authentication problems

Wednesday, September 30, 2009

A change in the way Snow Leopard does DNS may be the root of some of the problems with logging in to Active Directory. A previous reader report (Snow Leopard AD binding problems linked to DNS bugs) indicated that DNS issues may be behind Active Directory problems. Today, Al Pawlowski defined what the DNS issue is and provides a workaround:

Many of the authentication and DNS problems being posted may be due to something a colleague of mine found. That is: 10.6.x will not resolve a DNS name if the DNS record for the device has too long a TTL setting; TTL is the value shown just left of the "IN" in a Network Utility lookup for "any" info on a name.

The DNS servers where we work had a number of servers/records with TTL's of about 5.2 million seconds. None of these could be resolved by Mail, MS Remote Desktop, "connect to server" (ie. shares) and printing, so each app would not work unless the device's numeric IP address was entered. These devices could be resolved with Network Utility so getting the IP was not hard. Having our IT department DNS people shorten the affected device TTL's (to 604800 seconds, 7 days) made them all resolvable again.

Apparently, it is a (now known) problem with 10.6's mDNS resolver.

Something else that can give you trouble (if you are unaware) is that mDNS, when multiple DNS servers are specified, queries them in reverse order of specification, ie. last first; the last better be a good one for the name you are trying to resolve.

If you've tried this approach


Reader: Connecting to AD ate my Snow Leopard; No mobile account | Top of Page |

Tuesday, September 22, 2009

Peter Baird's brand new Mac had a melt down after binding to Active Directory. After much work, he got it running, but could not create a mobile account:

On a brand new MacBook Pro with Snow Leopard out-of-the-box, I could BIND to AD (Windows Server 2003) in our usual way. But Directory Utility then locked up, "spinwheeling" so badly I couldn't force quit or get out of the Finder. I had to hard reset using the power button.

On restart, the AD prefs were so corrupted that the local admin account was gone. Only login icon account choices were an AD System Administrator from a corporate AD Forest Domain in Hong Kong and some SystemMailAdministratorr49234909323! I had to factory reinstall OS from CD-ROMs.

After restart and disk repairs still properly bound to Domain, but creation of the Mobile Account login was prevented by the "headshake" password fail. No Mobile Account confirmation dialog. The login name and password are good because they authenticate to AD server shares. Had to create our user as a local account.


No write access in AD for OS X 10.6; 10.5.8 is okay | Top of Page |

Tuesday, September 22, 2009

Cameron Seward's Snow Leopard Mac can bind to Active Directory, but has no write access to shares:

I am just putting together a MacBook on our AD and had no troubles with the binding. When I go and log in as domain\username it takes it and logs it in just fine. But the issue comes to be that I have no rights to write anywhere on that account. If I log into a 10.5.8 machine I am able to write to the account just fine. So I know that my policies as working correctly. I am searching for a work around on this but have yet to find one.

If you've seen this

Another report of no write access in AD for OS X 10.6

Monday, November 8, 2010

Andrew Brezina responded to a previous report "No write access in AD for OS X 10.6" with some more details:

We are having the same issue. What is odd is that it does not happen with all of our servers, and being a domain admin seems to get around it. I am not making all my users domain admins so we are stuck with this until I figure out a work around. I am starting to think this has everything to do with the following:

A. Our domain is (domain).local
B. Our DC has "_" in its name.
C. Because of the previous two issues Kerberos struggles to stay authenticated.

This of course opens up the void between Mac and PC integration, which I have been sucked into…

If you've seen this problem


Reader's Mac OS X 10.6 Server requires forced-unbind after restart | Top of Page |

Tuesday, September 22, 2009

Seth Tanner must force-unbind when he reboots Snow Leopard Server:

I have been successful in binding Snow Leopard to Active Directory. The problem comes when I reboot Snow Leopard Server it no longer talks to Active Directory, I can force unbind and rebind no problem, but it is hugely inconvenient.

If you've seen this

Snow Leopard clients requires forced-unbind from AD

Monday, August 30, 2010

Dean Cole is having a problem with Snow Leopard clients requiring force-undbinding:

Hi I am just contacting you with regards to a post on your site on the 22nd September 2009 titled Reader's Mac OS X 10.6 Server requires forced-unbind after restart. I am experiencing the same issues on my Snow Leopard clients however it doesn't seem to happen every time the machines are restarted. Just the majority of the time!

If you've seen this

TIP: Apple fix for Snow Leopard AD force-rebind issues

Thursday, September 2, 2010

Dean Cole followed up his Monday report with the solution to his force-rebind problem after restarting Snow Leopard clients. Turns out his fix, described in Apple Support article TS3248, is the same that another reader reported as the solution for "Snow Leopard clients bound to Active Directory getting stuck in screen saver mode." Cole reports:

I actually found a KB article on Apple's website to fix this, the fix has solved the issue on all of my Mac clients running Snow Leopard 10.6. I'm not sure if this fix works on OS X server as I am not experiencing any AD issues on that to try it out.


Snow Leopard Software Update hangs for Active Directory users | Top of Page |

Tuesday, September 22, 2009

Marc Berger can't run Snow Leopard's Software Update on Macs bound to Active Directory:

Just wanted to send you another Snow Leopard issue for Active Directory users to post on your site. It appears that Software Update will run, but when it gets to the place where it installs the updates, it will hang and not run at all. This is even in the case of an Active Directory user who is designated as an administrator of the local computer. I am running 10.6.1 as well so that update did not fix this issue. The workaround for now is to login with a local OS X administrator account and run Software Update from there.

If you've seen this problem

Readers say 10.6.2 update doesn't fix some AD problems/Software Update issues

Wednesday, November 11, 2009

Although Apple said that the Mac OS X 10.6.2 update fixes a problem with mobile accounts in Active Directory, readers are reporting that other Active Directory problems persist:

John Thayer still has one problem with Snow Leopard after the update:

Just letting you know that Snow Leopard Software Update for Active Directory users still fails on 10.6.2.

Tyler Thorsted:

10.6.2 update does not seem to fix my many active directory issues. Particularly the issue with Software Update not being able to install.

Sebastien Gastaldi still has the problem with Snow Leopard Server requiring a forced-unbind after it restarts:

I got the exact same issue with SL 10.6.2 updated this morning.

how the 10.6.2 update affects these problems for you.

10.6.2 Active Directory problem with Software Update

Monday, November 23, 2009

Paul Nast is having the problem with Software Update on Mac OS X 10.6.2 not working with on Active Directory networks:

I am also having the AD/Software Update problem on Snow Leopard 10.6.2. It works when I login with a local OS X administrator account.

If you've seen this problem

More accounts of Snow Leopard's Software Update failing in AD

Monday, November 30, 2009

Readers continue to report that Snow Leopard's Software Update is crashing on Active Directory bound Macs: Jacob Parks wrote:

I have the same problem when trying to do Software Updates. The logged in account has Admin privileges. When I perform the update, the window just disappears but Software Update is still running. If I log in as a local admin, all is well. I have 10.6.2.

Ken Maynard in New Zealand:

Same problem as Paul Nast 23/11/09. A normal user used to be able to run Software Update. That user is authenticated by AD, and has his home directory on a Windows Server share. Now, the Software Update crashes with no visible evidence, apparently during file download. The original admin user locally authenticated and with a local home directory has no such problem.

Our problem with Office 2004, reported earlier, has not gone away, even though there have been several MS Office updates and Apple SL updates downloaded and applied. Again, no problems with the local admin user.

The earlier fix from Epson using an SL-compliant driver for the TX700W no longer works. Printing is OK, but scan fails on saving image to disk. Again, no problems with local admin user.

Rosetta and AD seem to be common factors in problem apps: Office 2004 and Epson scan both use Rosetta.

Scott Gingerich:

I also have this problem, and have had since the upgrade to 10.6.0. It still exists on 10.6.2.

Another Snow Leopard Software Update issue with AD

Wednesday, February 3, 2010

James Pennells in the United Kingdom has a problem with Software Update in Snow Leopard on bound to Active Directory similar to the previously reported problem, but it started with Mac OS X 10.6.2:

I just wanted to say that I also have this issue. I am running a 2.2Ghz MacBook Pro, which came with Leopard. I decided to do a fresh install of Snow Leopard, all went well. Connected to AD, still fine. Software Update worked up to 10.6.2, but now Software Update just disappears from my screen when I click Install updates.

If you've seen this

Reader confirms Software Update problem and workaround with Active Directory Macs

Monday, March 1, 2010

Travis Glessner confirm a problem and workaround with Snow Leopard clients bound to Active Directory and Software Update:

I tried to run software updates logged in as my active directory account and the updates never install. I logged out and logged in as local administrator and it worked. Thanks for the tip.

If you've seen this

TIP: Workaround for Software Update, Active Directory bug

Monday, March 22, 2010

Kurt "CoolAppz" sent us a workaround to the Snow Leopard problem on Active Directory networks where Software Update fails when trying to install an update. Kurt uses Terminal install an update:

My iMac, running Mac OS X 10.6.2, connected to a Windows 2008 SBS Active Directory, also exhibits the same issue with Software Update. It starts, but then closes and nothing else happens. This is with an administrator-enabled account on the Mac. Strange thing is, I just reinstalled my Mac OS. Before the reinstall (also using 10.6.2) I didn't have this problem.

I have a workaround, though. I start Terminal and run the following command:

sudo softwareupdate -i -a

This installs the software updates without a problem. I also confirmed that logging on as a local administrator also works.

Hopefully, Apple will fix this problem soon as it is quite annoying. I now check Software Update using the GUI, and if I see there is an update, I run the Terminal command.

If you've tried this suggestion

TIP: 10.6.3 may help Active Directory/Software Update problem

Wednesday, April 7, 2010

Kurt "CoolAppz" updated his previous fix for the problem of Software Update failing with Macs on Active Directory networks. He said that the Mac OS X 10.6.3 update helps, but that the update should be applied before binding the Mac to the domain:

A small update on the issue. I have just bought a new iMac 27", which came preinstalled with 10.6.2. I updated to 10.6.3 before putting it in the domain. This machine does not have this problem.

Also, I reinstalled my 20" iMac. But, I used a different install order. I installed Snow Leopard (10.6), then applied 10.6.3 update and all the other patches it finds before adding it to the domain. Now, Software Update works perfectly.

So, I guess it is solved in 10.6.2 (10.6.3) but it won't solve the problem if it is already part of the domain. Once the patches have been installed, then put in the domain, it seems to work as it should.

If you've seen this work

TIP: another workaround for Software Update hangs for AD users

Friday, May 21, 2010

Michal Mysliwiec found a fix for the problem of Snow Leopard's Software Update hanging for Active Directory users. He changed a setting with the Active Directory plugin:

I had this problem too. My Active Directory user have admin flag in Accounts settings checked. But Software Update won't install anything.

I had to change Active Directory plugin settings. There is a place where you can add domain groups that will have privileges to administer your computer. I just added "DOMAIN\domain users" and Software Update works fine. This also solved some other problems with user privileges in other applications.

If you've tried this approach

More on Snow Leopard Software Update/AD Issue

Wednesday, February 2, 2011

Terrell Jamison is having the problem with Software Update not working on Snow Leopard Macs with Active Directory. Like other readers, logging in as a local user gets around it. He mentions that he tried a fix, but we don't know which one of the two (here and here) he tried. Jamison's report:

I too am experiencing the same symptoms with performing updates, with a network user login with admin rights performing updates. If I log on local to the workstation, the updates work. After reading the fix, I logged in locally and was able to download the latest OS download (10.6.6). Network users logging in via Active Directory are now able to perform their own updates with success.

If you've seen this


Note: there is also a discussion about this topic on our Snow Leopard File Sharing Tips and Reports page.

OS X 10.6 Word can't save on Win-based home directory; scanner fix | Top of Page |

Monday, October 12, 2009

Ken Maynard has three problems with Snow Leopard in Active Directory, where the home directory is on a Windows server. He can't save files from Word 2004, and loses network connections after waking from sleep. He fixed his problem with a network scanner. Maynard's report:

We had Leopard and Office 2004 on iMac in a Windows 2003 domain. User home directory is on a Windows server. We upgraded to Snow Leopard, and now Word 2004 can't open normal.dot, and you can't save a file anywhere whether local disk or Home dir on Windows share. Locally authenticated (admin) user still works OK, but can't save on Windows share. You can drag and drop and delete files on the share OK, and TextEdit works OK with the .doc file where Word doesn't!

Also, an Epson TX700W network scanner behaved similarly - it scans but then couldn't write the scanned file. It worked with Leopard. To fix it, I found a Snow Leopard driver on the Epson site which fixes the problem with scanning on SL if you are an AD user. Perhaps Microsoft should ask them how they fixed it! Now using Open Office instead of Office 2004.

Another problem, which existed with (I think) Tiger, but went away with Leopard, has re-appeared. When the iMac wakes after sleep mode, it can't talk over the network. I have to unplug the Ethernet until it notices the network has gone, and then re-connect it. Otherwise it just sits there sulking.

If you've seen these issues

TIP: Fix for Macs in AD "file is locked" error

Thursday, December 10, 2009

Chris Eads described a problem he was having with Macs in an Active Directory domain, where the Macs could not save a file to a server a second time after saving it once. He also sent us the fix. The problem is sounds similar is some ways to the issue problem of saving Office 2008 files to SMB servers on an Active Directory network. Here is Eads' report:

After spending a few days on this one, we figured it out.

The Problem: We joined the 10 or so Macs in the company to our Active Directory domain and in the magic triangle configuration (Mac OS X 10.6.2 Server). When the Macs were independent of the domain, and the users were connecting to the shares using their domain credentials, everything worked fine. When the Macs got hooked in via the directory plugin, users could create a file in Illustrator (for example), and save it once. You could not, however, save it a second time (sometimes third). Illustrator gave a "file is locked ID = -54" error of sorts.

Solution: In a long session of trial and error, I tried saving to the administrative C$ share on my Windows 7 desktop, which was owned by "NT SERVICE\TrustedInstaller". Creating a share on Win 7 had the same error behavior as before, when the shared folders owner was changed to TrustedInstaller, it worked fine. The following challenge was to port that solution to a XP/2003 environment, which doesn't have that account. My boss, out of a leap of logic, tried the "NETWORK SERVICE" domain account as the owner of the folder on 2003, and everything works. Obviously the sharing/ntfs permissions have to be set properly on top of that. I'm sure I'm not the only one that's had this problem, so I figured I'd toss it at you guys.

If you've seen this, or tried this workaround for the Office 2008 problem,

Reader verifies fix for Macs in AD "file is locked" error

Wednesday, February 24, 2010

Jim Myers verified a fix for a problem where Active Directory Macs could not save a file to a server a second time after saving it once:

I tried this fix and it worked perfectly - I've been having this issue for months, thanks! I have 10.6.2 and CS4.

If you've seen this

Reader questions fix for Macs in AD "file is locked" error

Monday, March 8, 2010

Christopher Sokolov replied to TIP: Fix for Macs in Active Directory "file is locked" error, with a cautionary question:

I appreciate the work on this serious problem including the suggestion about changing ownership. I suppose I'm "stuck" psychologically on calling this a fix -- can't/doesn't this break the whole schema of ownership/permissions on Windows servers?

If you know the answer to this

Readers differ on fix for Macs in AD "file is locked" error

Thursday, March 18, 2010

Two readers had different experience on the using Network Service as the owner as a fix for the problem (described here and here) where Macs can't save a file to a server a second time after saving it once. (The fix is also described here.) Steven Ahmet had success:

I too can verify that adding the "NETWORK SERVICE" user as the owner of the top level folder of a share on a Windows 2003 Server, then applying that to sub-folders and files, fixed the problem. I was specifically having this issue with 10.6.2 and Photoshop CS3 and CS4 attempting to save any type of file for a second time. Applying the solution fixed the issue straight away.

I know "psychologically," as another user said, this doesn't seem like a fix, but at the moment it's working, and this was a real deal-breaker in our decision to purchase any new Macs at the moment.

The procedure didn't work for Jason Cutler:

I'd like to report that unsuccessfully tried the fix of adding NETWORK SERVICE as an owner of the share that couldn't be written to from Excel (or Office apps rather)

The Owner NETWORK SERVICE was given Full Control. (Special Permissions is grayed out.) The Mac was restarted after this change was made. No effect.

The server is Windows 2003 R2 Standard SP2, and I can confirm the other facts are the same; My frustrated user is using 10.6.2 with Office 2008 and the Mac is bound to Active Directory. AFP works fine as does using the Finder to copy the files onto the SMB share.

Note: there is also a discussion about this topic on our Snow Leopard File Sharing Tips and Reports page.


Mac OS X 10.6.2 issue with mobile accounts ("Allow Administration by"); losing Admin rights

Wednesday, February 24, 2010

Ryan Miles reports a problem with problem with mobile accounts and Snow Leopard:

I'm running 10.6.2 bound to Active Directory. Mobile accounts, which should have local "administrator" access revert to "standard" users when systems bound to the domain, do not have direct access to the domain (i.e. system is away from the office network). However, once a network connection with direct access to the domain is re-established (e.g. connected via VPN or back in the office), the mobile account is once again granted local "administrator" access. 10.6.2 does not appear to be caching this information to allow the mobile accounts to remain local "administrators", when a direct domain connection is no longer available.

This does not appear to be a problem with 10.5.

If you've seen this problem

More reports of losing Admin privileges with mobile accounts

Monday, March 1, 2010

Two readers responded to last week's report Mac OS X 10.6.2 issue with mobile accounts ("Allow Administration by"). Gabriel Preston reported some more symptoms:

I am experiencing this problem as well. When connected to the work network I can authenticate and have full access to my Mac. When at home and not using my work network, I cannot do anything requiring Administrator privileges; can't install applications, make changes to system settings, etc. I am on OS X 10.6.2

Tony Trumbo has also seen this with Leopard:

We have seen the same issue that was mentioned on MacWindows regarding computers losing administrator access when not on a network with access to a domain controller. However, we have seen this issue with every version of 10.5 on our network. We also lose managed settings when those machines are not able to access our Xserve. We haven't figured out if it is something to do with our "Golden Triangle" configuration or something else.

If you've seen this

TIP: AppleScript workaround for losing admin privileges with AD mobile accounts

Monday, March 8, 2010

Steve Humiston responded to our report More reports of losing Admin privileges with mobile accounts by sending in an AppleScript that he uses to work around the issue:

do shell script "rm -R /Library/'Managed Preferences'/`users`/com.apple.systemconfiguration.plist" user name "root" password "whateverrootpasswordis" with administrator privileges

Although I don't know why it happens, I just know the mobile account still uses that managed .plist. Once removed the user is free to use the machine as they'd like. Once back, the server will auto push that .plist back upon the user so they will still be managed while in your domain.

Make this AppleScript a run-only application (save as run-only application in AppleScript editor). Call the app "for home use" and have your users click it and they should be good. It's merely a workaround. Remember, it will have to change when you alter root's password.

If you've tried this approach

Meanwhile, other readers wrote to further describe the symptoms they are seeing. Blaine Reid:

We have seen this issue occur with 10.5 and 10.6. Machines are bound to Active Directory and work fine when connecting to shared network volumes, file sharing and other AD capable functions. However when the user tries to install software, the machine will kick it back and pop up the "You must have administrator access in order to install this software. Contact your system administrator" (or something similar to that message). It will occur when the mobile account users is connected to the domain or off the domain. Our only solution at this time is to log in as a local administrator and install the software and then let the user log back in under their credentials.

Carl Limyao also sees the problem:

I also experience these same symptoms. As long as my machine can see the domain controller when I login, everything is golden. If not, I lose admin privileges and it also takes quite sometime to login or unlock my screensaver.

TIP: Fix for AD mobile accounts losing admin rights

Friday, April 8, 2011

Kevin Worden sent us his solution to the Active Directory problem of Mac mobile accounts on losing administrator rights and reverting to standard user privileges:

I was having the mobile account losing admin rights for a long time since 10.5. All my Macs are bound to an unmodified 2003 AD domain. Here is what I use to work around the issue. I add the current user to the Local admin group.

To give/remove the current user's Local Admin Rights you can run these applescripts. You only need to run them once. The user will keep the Local Admin Rights until you remove the rights. Save each as run-only app. Replacing "root" and "rootpassword" with your own local admin account.

To give current user Local Admin Rights:

do shell script "/usr/sbin/dseditgroup -o edit -a `users` -t user admin" user name "root" password "rootpassword" with administrator privileges

To remove the current users Local Admin Rights:

do shell script "/usr/sbin/dseditgroup -o edit -d `users` -t user admin" user name "root" password "rootpassword" with administrator privileges

For dseditgroup reference:

/usr/sbin/dseditgroup -o(operation) edit(opens to edit) -a(dds)/-d(eletes) root(user to add) -t(group type) user(you want to add a user) admin(group to add to)

Hopefully Apple will fix the issue some day but until then I know I have this for the users I need to have admin access outside the office.

If you've tried this approach

Tip: Another take on "dseditgroup" fix for AD loss of admin rights

Monday, September 12, 2011

A reader shared a fix for the Active Directory problem of Mac mobile accounts on losing administrator rights and reverting to standard user privileges. His fix is similar to one posted in April for Snow Leopard. This reader (who wishes to remain anonymous) sees the problem with Lion:

Managed admins are just users when logging on offline - After joining 10.7 to my 2003 AD, SysPref/Accounts showed my ID as "Admin, Network, Managed". But if I logged on from home (no DC authentication), I lost admin rights. The following command fixed the problem:

dseditgroup -o edit -n . -u current_local_admin -p -a $USER admin

This command asked for the password of "current_local_admin" and then added $USER to the local admin group for offline authentication. Also, using" dseditgroup -o read admin" lets me confirm the current group membership.

If you've tried this approach in Lion or Snow Leopard .

Apple, MS, say Win 7 client can't join OS X Server PDC Domain

Saturday, March 13, 2010

This week, Apple announced that Windows 7 clients and Windows Server 2008 R2 cannot join a directory domain mastered by a Mac OS X Server primary domain controller (PDC).

In a tech support article entitled Mac OS X Server: Cannot join Windows 7 to a Mac OS X PDC Domain, Apple says there are no workarounds to the problem. It links to a Microsoft support article that says that Windows 7 and Server 2008 R2 no longer support to Windows NT 4.0 SP6A domains, which is what Mac OS X Server provides to Windows clients......Read full story here

TIP: Workaround for Win 7 client not joining OS X Server PDC Domain

Monday, April 26, 2010

Jens Lodholm responded to our article about Apple's announcement that Windows 7 clients and Windows Server 2008 R2 cannot join a directory domain mastered by a Mac OS X Server primary domain controller (PDC). Lodholm found a possible workaround in the Apple forums:

According to a thread on Apple's Discussion boards, I quote:

I have a possible solution for some. It doesn't exactly BIND the Windows 7 machine, but at least you can have users authenticate against your OD servers instead of having OD bound to an AD server.

Step one: Download and install pGina 2.x (http://sourceforge.net/projects/pgina/files/)

Step two: Download the LDAPAuth plugin from same location

Step three: configure pgina with the appropriate ldap settings for your environment. ()

Users can now log in.

I'd be interested to know if this works for anyone. I'm not currently in a position to experiment with this option, but will when I have the chance.

We'd also be interested to know if this works for you. If you've tried it

Reader's Snow Leopard clients losing AD binding, offers workarounds

Monday, March 22, 2010

Mark McNeil finds that his Snow Leopard iMac clients lose their Active Directory binding. He has to two temporary fixes:

I'm having problems with OS 6.2 "unbinding" from Active Directory (Windows Server 2003). We have 15 iMacs running OS X 5.8 that we have no problems with being bound to AD. We also have 15 MacBooks with OS X 6.2 and they are constantly "unbinding" from AD. To correct the problem I need to log in as the local administrator, unbind and then rebind to AD. That fixes the problem until the next restart or after a certain amount of time goes by. The other fix is to delete the kerberos.mydomain.plist and restarting the DirectoryService.

I am running two Windows 2003 Active Directory servers. They are also my DNS and WINs servers. One is the DHCP server. On the Macs I am just using the Directory Utility to bind them to the domain, which is sspp.local.

If you've seen this problem and tried these workarounds

Losing Active Directory binding seen on Leopard and Snow Leopard

Thursday, March 25, 2010

Chris Neely responded to our report of Snow Leopard clients losing Active Directory binding, saying that he sees it on Leopard clients as well. His workaround is different than that of the previous report:

I have had this problem for quite some time dating back to 10.5. Although, I only started having this problem when we moved to Windows 2008 server. For me this problem really only is noticed when a users AD password is about to expire and they attempt to change it. Rebinding fixes until the next time they try to change their password. Happens with my 10.5 and 10.6 clients. Very strange because not all clients experience this even though they are all configured exactly the same.

If you're seeing this problem

Possible fix for Macs "unbinding" from AD: change passinterval

Tuesday, May 18, 2010

Anne Balish shared a suggested workaround for problems with Snow Leopard clients losing binding from Active Directory. She send us a script that changes the passinterval on the Mac clients:

I'm having problems with OS 10.6.2 "unbinding" from Active Directory (Windows Server 2003). We have 15 iMacs running OS X 10.5.8 that we have no problems with being bound to AD. We also have 15 MacBooks with OS X 10.6.2 and they are constantly "unbinding" from AD. To correct the problem I need to log in as the local administrator, unbind and then rebind to AD. That fixes the problem until the next restart or after a certain amount of time goes by. The other fix is to delete the kerberos.mydomain.plist and restarting the DirectoryService.

I am running two Windows 2003 Active Directory servers. They are also my DNS and WINs servers. One is the DHCP server. On the Macs I am just using the Directory Utility to bind them to the domain, which is sspp.local.

I had a similar problem on Macs running OS 10.5.8 and Centurion's MacShield (it's like Deep Freeze). The solution was to change the passinterval on the clients. I ran the following script via Apple Remote Desktop as root and haven't had any problems since:

dsconfigad -f -r -u ADadminusername -p ADadminpassword -lu localadminusername -lp localadminpassword

sleep 10

dsconfigad -lu localadminusername -lp localadminpassword -passinterval 0

sleep 10

computerid=`/usr/sbin/scutil --get LocalHostName`

dsconfigad -f -a $computerid -domain yourdomain -u ADadminusername -p ADadminpassword -lu localadminusername -lp localadminpassword -ou ou=yourOU,DC=yourDC,DC=yourDC -status

If you've tried this suggestion


TIP: fix for AD login problem; 10.6.3 update doesn't help

Friday, April 2, 2010

Sal Castiglione shared a fix for a Snow Leopard problem of only being able to log on to Active Directory with local accounts. (His problem may be similar to this previously reported issue.) The Mac OS X 10.6.3 update didn't fix the problem, but Castiglione found his own fix:

I was having AD issues with OSX 10.6. It bound correctly, but only local accounts could login. Attempting to login with domain credentials resulted in the shaking login window.

This was still occurring for me with 10.6.3. However, I found the solution, at least for our domain. I looked at a Leopard 10.5.x system, and saw that in Directory Utility, under Advanced Options>Mappings, the three options there (Map UID to attribute, Map user GID to attribute, and Map group GID to attribute) were UNchecked. This was different than Snow Leopard, where the default option in when adding an AD server has those checked. So I unchecked them on Snow Leopard, restarted, and now I can login to the domain.

Something else I ran into was that in order to join a computer to the domain, I needed to use the format of username@domain.com as opposed to domain.com/username

If you've tried either of these suggestions


TIP: Fix for slow Active Directory authentication times

Friday, April 2, 2010

Nick Carpenter sent in a tip to fix slow authentication to Active Directory, on his in a Windows 2008 R2 domain environment.

After we updated to 10.6.3, we were still experiencing longer than normal authentication times to the server. I found the solution for my sluggish authentication issues. I needed to specify our domain in the username when authenticating. After making this change I log in as expected. Seems that specifying the domain speeds up the process.

If you've seen this

TIP: fix for slow login with Snow Leopard, AD on .local domains

Monday, February 28, 2011

Josh Gilmour posted a fix on his web site for problems of slow Snow Leopard login and authentication with Active Directory:

I wrote up a post about fixing the slow logins/logouts/ and authentication on Snow Leopard 10.6 when using a Mac bound to Active Directory and the .local domain check it out at my blog here.

On his site, he describes the cause of the problem:

The problem lies within search policies on the OSX system. After the computer is joined to the domain, 2 entries are added to the search policy. The entry /Active Directory/All Domains is added to both the Authentication and Contacts search path. Since there is no way to change the Kerberos timeout value on OSX (that I am aware of), the system tries to either authenticate to all 3 directory domains ('/Local/Default', '/BSD/Local', '/Active Directory/All Domains'), or tries authenticating Active directory first even though it is in the bottom of the list.

Most of the time this has been seen when the domain is also a .local suffix. This MAY be due to problems with Bonjour (which also uses .local) and the .local Active Directory domain, but I'm not positive.

Gilmour's site also lists the fix. If you've tried it

TIP: Snow Leopard clients bound to AD get stuck in screen saver

Friday, April 2, 2010

Apple has posted a new support article describing a workaround to a problem with Snow Leopard clients bound to Active Directory. The article describes the problem:

When bound to Active Directory, Mac OS X v10.6 clients may not accept Active Directory credentials to dismiss the screen saver if it requires a password (that is, if "Require password to wake this computer from sleep or screen saver" is enabled in the Security preferences pane).

Apple's workaround, described in the article, is to edit the /etc/authorization file using TextEdit.

If you've tried this fix

Note: Apple updated this support article on May 19, 2010.

Reader verifies AD fixes in 10.6.3 update; Office, portable home directories OK

Thursday, April 22, 2010

Peter Kloss sent a report on the effect of the Mac OS X 10.6.3 update on Active Directory-related issues. He, like other readers, verified that the update fixes the problem of saving Office files to servers. He also reported that portable home directories now work for Active Directory-authenticated users. He also sent a link to the Apple article about problems unlocking a screen saver when using Active Directory credentials (described directly above).

I am happy to report that 10.6.3 does indeed fix several really annoying bugs in 10.6 integration with Active Directory. Top of the list must be the reported problems working with MS Office files on SMB shares. In 10.6.2, like many of your readers, I could not save over documents opened from SMB shares. Moreover, I could only open xml format files as access to older .doc, .xls files was denied. OpenXML format files would become read-only after the first save and so on. 10.6.3 appears to have fixed these multiple problems.

I have a network home folder on a NetApp filer, so not being able to work with these documents was a right pain! I also could not apply the fix of changing the owner to 'Network service' as this would break Windows access to my home share (key Windows file sharing features implemented by Group Policy do not work such as redirected home folders unless the owner is the logged in AD user - hence my unhappiness with that 'fix'). I would recommend that if any readers have changed the ownership to 'Network Service' they change it back after applying 10.6.3.

All is not happy in the performance front all the time with a network home, the SMB driver does seem to slow down every hour or so and produce the spinning wheel from time to time, but hey, it works, so I'm happy. (And Spotlight never manages to complete indexing my home folder!)

The other really big fix is that Portable home directories now work for AD authenticated users - even with my network home being on a Filer. You have to be careful if you are a existing Mac user with a network home folder because the portable account process overwrites the network home Library folder with the contents of the Default User template on the Mac from which you are creating the portable account (there probably is some way of preventing this but I haven't researched it yet). My home being on a filer makes it easy to recover from a recent snapshot, but it's a pain. However, this just proves that network - local home sync actually works; one needs to exclude the Library from the list. This is no worse than any other networking scenario for a user who logs into several different systems with the same network account and connecting / syncing with a single home folder.

I should also mention this Apple KB article just released to do with potential problems unlocking a screen saver when using AD credentials. (Note the use of the word 'may' - but someone I know does have the problem.)

TIP: Fix for Snow Leopard AD clients getting stuck in screen saver in .local Domains

Tuesday, June 1, 2010

John Gilbert has the problem where Snow Leopard clients bound to Active Directory get stuck in screen saver mode. Two readers previously said that Apple support article TS3287 fixed the problem. Gilbert reports that it didn't for him. But he found another Apple Tech support article, TS3248, that did. This fix is to lengthen the default timeout for .local name lookups by editing an info.plist file. Gilbert reports:

I seem to have the symptoms described in your tip of 2 April 2010. The Apple fix made no difference. What did help was another Apple fix: http://support.apple.com/kb/TS3248. This is one of the problems related to having an AD domain which ends in .local.

If you've tried this


Apple's fix for AD clients stuck in sleep doesn't work for reader

Friday, June 4, 2010

Bob Nine is having problems with Active Directory Mac clients that go to sleep and can no longer log in. He tried an Apple workaround we described earlier this week for Macs stuck in screen saver mode, to no avail:

This is not working the way I want. I am a long time Windows IT geek. I own several Macs myself. This is the first one we are getting into the AD network at the office.

My issue is when I put the Mac to sleep (closing lid) and go to a meeting, I cannot log back in. I can log into another name, then get the wireless going, and then switch back to the AD name. It is like the AD profile is not cached. I see the home directory on the local HDD, but it is NEVER an option when I am off the network. I ran the fix suggested in your post, and that assisted in the wired solution speed. It did not change the wireless solution or the offline situation. I will not get this approved for general use without offline user profile access.

If you can help

TIP: Fixing Snow Leopard AD clients that can't log in after sleep

Monday, June 7, 2010

Two readers responded to Bob Nine's report of Snow Leopard Macs not being able to log in to Active Directory after going into sleep mode. Both offered advice for how to deal with the issue. The first report was from Bob, updating his previous report with some advice he received from Apple:

We had a breakthrough after I sent the previous email: I called Apple Support. It was a good experience. I signed up on the website and the phone system called me. Talked to the first guy for a few minutes, then he sent me to his manager. His manager did not know, but researched it on their knowledge system. We fixed this very easily. Here is the process......Read entire story here

Reader has no success with AD/screen saver tip

Wednesday, August 4, 2010

Shaun Runham reports no success with the Apple workaround for Snow Leopard clients bound to AD getting stuck in the screen saver:

I tried this one (sadly didn't work) and also another tip (found via Google) is to kill the DirectoryService every 10 minutes. This didn't work either. It doesn't happen every time but most of the time after my lunch hour. I will keep looking and will hopefully find the solution one day. Then (at long last) I will be able to go to lunch and not have to power off the Mac to be able to login with any AD account.

Note that we also have this suggestion from last month. If you've tried it

Current news on the MacWindows home page


Snow Leopard Server for Dummies
By John Rizzo

A 432-page book that simplifies the installation, configuration, and management of Apple's Mac OS X 10.6 Server software. Support Mac and Windows clients for file sharing, email, and directory services; Incorporate a Mac subnet into a Windows Active Directory domain, manage Mac and Windows clients, and configure security options, and more.

Click here for more.


Stanford SIG articles point to weird ACL believe in Mac SMB Server

Thursday, April 22, 2010

Two technical articles at Stanford University's Mac Special Interest Group describe problems with Mac OS X Server's implementation of SMB with Windows clients, and offer possible workarounds. An article called "Snow Leopard's Samba adds unwanted directives to shares" describes some differences in how Leopard and Snow Leopard handle ACL permissions.

Another article, titled "ACLs not being properly honored in Samba with XP clients," describes the behavior of Mac OS X Server 10.5 with Windows clients. This second article offers a "probably solution," editing the smb.conf file by "adding nt acl support = no." We've reported this before, but it hasn't worked for all readers. The first article describes why this solution may not work with Snow Leopard Server.

If you can shed some light on this



TIP: Apple fix for Mac AD users not being able to log in

Tuesday, May 25, 2010

A new Apple support article describes fix for Active Directory users who receive an "unable to log in to the user account" error message. The article describes the symptoms occurring when users have home folders on the server. The fix is to edit the Mac client's /etc/auto_master file to comment out the /Network/Servers entry:

# Automounter master map
#
+auto_master # Use directory service
/net -hosts -nobrowse,hidefromfinder,nosuid
/home auto_home -nobrowse,hidefromfinder
#/Network/Servers -fstab
/- -static


Dock icon for Snow Leopard AD network home folder missing

Friday, June 4, 2010

A reader named Augwell posted in our new discussion forums about a problem he is having with Snow Leopard and Active Directory-based home folders. Here's a portion of his report.

"...I can't seem to get the user's network home folder to come back to the dock. I have tried everything I know of including unbinding and rebinding the computer, changing settings for "force local user home folder" etc. I have a feeling that a simple plist file controls the automount and dock folder icon, but I can't find any information to lead me in the right direction."

Read the full report here. If you've seen a similar issue, please post a reply to Augwell's post here.


Reader says AD causes slow Snow Leopard SMB

Monday, June 7, 2010

Dan Tidswell did some testing and believes that Active Directory causes slow SMB connections in Snow Leopard:

After reading your post I decided to take some time out today to debug my problems with SMB connectivity to my Windows 2008 R2 server. I was experiencing very slow connections to shares and then slow transfer speeds when I copied data to/from the shares.

Essentially, for me the problems seem to be related to Active Directory and Snow Leopard. Once I rebuilt the server (without installing Active Directory) everything worked fine. I could connect to shares almost instantly and transfer speeds on my GB switch were around 30-40MB/s. I then took a backup of the server and promoted it to a DC. The presence of Active Directory introduced all of my original problems.

I then re-installed using Server 2008 (not R2), without AD installed I had no problems, in fact transfer speeds improved to around 50-60MB/s. Again, once I promoted the server to AD all the original problems returned.

So there you go, Snow Leopard seems to have issues with AD, or at least in this case.

If you've seen this

NOTE: There are also reports about slow SMB, unrelated to Active Directory, on our Snow Leopard File Sharing Tips and Reports page.

Snow Leopard SMB file copy slow when connected to Active Directory

Wednesday, February 2, 2011

Mark Sones responded to the report "Reader says AD causes slow Snow Leopard SMB," saying that file sharing is faster when Windows Server is not a domain controller:

As per the above, I can confirm I've found Mac SMB file copy performance to be slowed significantly after promoting a Windows 2008 R2 server to a domain controller / active directory host. Rebuilding the server and not making it a domain controller has made a big difference to the speed!

If you've seen this


New Apple doc on how to Modify the AD schema for Mac access

Friday, June 18, 2010

Apple has a new (or updated) how-to white paper called Modifying the Active Directory Schema to Support Mac Systems, dated May 2010. Modifying the schema is one of three basic ways of adding Macs to an Active Directory network is to modify the schema on the server. (The other two are to install a Mac OS X Server, or to use a third-party product, such as Thursby Software's DAVE, Centrify's DirectControl, or Likewise Software's Likewise.)

Although many system admins don't like the idea of modifying the schema, the paper provides step-by-step instructions to do so, which Apple calls "extending the AD schema to manage Mac systems.?

What do you think? Is this a good idea? Post your opinion in the MacWindows Active Directory forums.


Active Directory error "bad forest or domain"

Tuesday, July 6, 2010

Michel posted a note in the forums seeking help with an Active Directory error message he's seeing:

I have a small problem with laptop snow leopard 10.6.3 or 10.6.4 and win 2003 AD. Network ok, attach manually to share folder or share printer ok with my administrator login, but snow leopard does not attach to AD. An AD plugin said "bad forest or domain". I have testing with uppercase, lowercase, .com or not, etc.

If you can help, please post a response here.

TIP: Fix for Mac AD authentication failure after reboot on .local domains

Wednesday, August 4, 2010

Patrick Timms shared a DNS fix for an Active Directory authentication problem with .local domains. His article describes what is happening and provides a StartupItem shell script:

This is a general post aimed at everyone who has a .local domain and is still frustrated with the Active Directory authentication issue on Snow Leopard, i.e. where at least 50 percent of the time the Macs will fail to authenticate AD users following a reboot and display "This domain is not responding" in Accounts -> Login Options. I haven't seen any other definitive fixes for this problem yet, so I thought I'd post something that works 100 percent for us.

The problem, as I understand it, comes down to Apple's buggy Multicast DNS Responder implementation (the processes "mDNSResponder" and "mDNSResponderHelper"), whereby .local domains conflict with the Bonjour service and the KDC(s) for the Windows domain can't be resolved, causing authentication to fail. None of the multitude of "fixes" I've seen posted so far have had much success at my workplace.......Read entire story here

Readers says 10.6.6 update fixed Snow Leopard AD binding

Monday, February 14, 2011

John Haynes said that upgrading clients to Mac OS X 10.6.6 fixed a problem where the Macs drop Active Directory binding after the client reboots:

I am a very new Win/Mac administrator with many years as a purely Windows net admin. I have been an Apple user at a stand-alone level for a while. Recently we decided to put together a Mac lab on our network and quickly ran into the bug outlined on your site where OS X 10.6 client drops the binding to the AD server after a reboot. In our case it worked fine for different users until the Mac was restarted, then they would fail to authenticate until we logged on as local admin and rebound to the AD server.

We found lots of discussion about this but nobody had a solution that seemed to work for us. However there is a solution and in our case it was simple: it seems this bug has been corrected in 10.6.6 for as soon as we applied this combo update to our client systems they were happily authenticating regardless of the number of restarts.

If you've seen the 10.6.6 update have any effect on this problem

TIP, Snow Leopard AD workaround: remove home path, then recreate

Monday, September 20, 2010

Although we have some posted workarounds to Snow Leopard Active Directory issues, Timothy Skimina send us another:

Long before I found your workaround I was also successfully doing the following for Macs running 10.6.x and bound to a Windows 2008 cluster. As a workaround:

  1. Remove the Home folder path specified in Active Directory for the user.
  2. Log in to the Mac OS X v10.6 client.
  3. Create the mobile account when prompted.
  4. Specify the home folder path in Active Directory for the user.

The user should now be able to log in to the Mac OS X v10.6 client.

If you've tried this approach

Spotlight re-indexes after each login for AD users

Monday, September 27, 2010

A reader in our Macs and Active Directory forum reports that his Snow Leopard clients reindex their Spotlight index when logging into Active Directory, a process that takes several hours. You can read his report in our forums. If you've seen this, please post a reply to his report in the forum.

Migrating existing local user to Active Directory account

Monday, October 11, 2010

Our Macs in Active Directory forum has a thread about how to migrate existing local Mac users to an Active Directory account. A reader provides a link to the answer. If you've done this, please post a reply in the forum.

TIP: Same name for local and AD accounts can cause mobile login problems

Monday, January 3, 2011

Michael Hughes responded to the article "TIP: Apple workaround for Snow Leopard AD login, mobile problems." He had a different problem with creating a mobile account, which he thinks was caused by using the same name for the local user and AD accounts:

I've been unable to get a mobile account to log in when the laptop is off the network. I had intentionally not checked the require confirmation when creating mobile account checkbox, and expected the mobile account would be created for me automatically. It was not. So I went back and enabled that checkbox, rebooted, authenticated to the network at login, and it does not prompt me to create a mobile account, nor does it seem to create one. The user's object does not have a home directory defined in AD.

I think it was because I had named the local user account the same as the AD account, and when I logged in with the AD account it used the same home folder and settings. In order to get the mobile account created I deleted the local/AD account and re-create it as strictly an AD account by logging into AD. This time it prompted me to create a mobile account.

If you've tried this approach

Complications with using uppercase domain to bind to AD

Monday, January 3, 2011

Michael Hughes used an all-uppercase domain to clear up binding problems with Snow Leopard and Active Directory, as other uses have reported doing. However, a discovered some other factors:

It is possible that I made repeated typos when attempting to bind it, but my observation was that the domain name appeared to need to be entered in upper case: OURDOMAIN.EDU. Curiously enough, after it was successfully bound and I examined the Directory Utilities properties window, it displays as lower case: ourdomain.edu. It never did accept my prefix of 'stat', but it found the machine object nonetheless and is now joined to it. I attempted it with the stat prefix because I kept receiving this error:

Invalid domain. An invalid Domain and Forest combination was specified. You should enter a fully qualified DNS name for the domain and forest (e.g., ads.company.com).

It was also necessary to provide the full CN=path to the OU the object resided in.

If you'd tried using uppercase domain names to get around Snow Leopard/Active Directory binding issues

TIP: fix for Active Directory lose of binding/slow SMB: uncheck search all domains

Thursday, March 3, 2011

Israel Adame fround a solution for Snow Leopard clients in Active Directory that he believes fixes problems with losing binding and with slow SMB file sharing:

I have seen all of the probable solutions and tried everything and still I am getting issues with 10.6.6 and after rebooting the Mac gets unbind. Or the Mac gets Network Accounts Available even when not accessing the list of users from AD. But the thing that I have done that has solved all my issues with AD on the Macs is to uncheck the box to search on all domains. For some reason I am seeing that when the Macs have this option checked, it searches through out the forest on the same domain controller more than once, so AD stops the handshaking of the authentication.

I hope this helps like it did on our Network, since then I have not seen the Macs lose the binding or slow SMB.

If you've tried this

TIP: Uncheck Allow Authentication from any domain for Mac AD problems

Wednesday, April 20, 2011

Steven Wells sent a fix and an explanation of problems with Macs losing their binding to Active Diretory:

Unchecking "Allow authentication from any domain in the forest" is working at our college. We have been beating our heads on this for about 2 terms, with no understanding of why it works in some places and not in others. When we found this working, our IT guy said that the Security SID is being duplicated, when it looks in other domain forest, and that is what is causing the problem. This is the first time I have found an explanation for the problem.

If you've tried this approach

TIP: Extending AD schema for sync rules on Mobile accounts, w/o OS X Server

Friday, April 8, 2011

A MacWindows Forum reader has posted a description of how to extend the Active Directory schema to enable setting up synchronization rules for Mac home directories for mobile accounts. This is for a situation where there is no Mac OS X Server.

If you've tried this approach, please post a reply in the forum.

Win IT Mag reviews AD integration products for Mac

Thursday, May 26, 2011

Windows IT Pro Magazine has posted an in-depth review of solutions for integrating Macs into Active Directory. The review covers Centrify DirectControl, Likewise Software's Likewise Enterprise, and Quest Software's Authentication Services, and Thursby Software's ADmitMac. The reviewer test a number of features, including adding and removing the Mac client from the domain, migrating a user, changing settings using a Group Policy Object, and using cached credentials to log on when not connected to the domain.

Comment on this article in our Active Directory Forums.


General advice for logging into AD and Win servers

Wednesday, June 1, 2011

Eric Yeo in Singapore responded to the article about Macs not being able to log in to Active Directory after going into sleep mode with the general steps for logging a Mac into Active Directory and then the Windows Server:

If your objective is to logon to the Windows server:

  1. Go to System Preferences
  2. Go to User account
  3. Click login Options
  4. Look for Network Account Server -- Click Join
  5. Prompt you for the AD server
  6. Click the amend directory utility
  7. Click Bind

To logon to the Windows file server using your Mac as a client, the work around as the following:

  1. In the Finder, click the Go menu
  2. Click Connect to Server
  3. Input your server name or TCPIP address of the server
  4. Click Connect
  5. On registered User
  6. Keyin your AD UID (user ID) and password and click Remember in keychain
  7. After you have connected
  8. Choose the shared folder you want to access and it'll mount for you.

Hope this helps.

If this helps you (or not)


Local Mac admin getting parental controls applied in AD environment

Friday, July 1, 2011

Lindsay Robertson in New Zealand has a problem with Macs in an Active Directory where local administrators get restricted access, with parental controls applied to their accounts:

I'm having a very similar problem to "More reports of losing Admin privileges with mobile accounts." I have 5 separate Macs with 10.6.6 or later bound to Active Directory (only for print and file sharing) where a local administrator account gets parental controls applied to it each time the user logs in.

If I disable the parental control, it is fine until the next login. Deleting and recreating the account does not fix the problem. I've no idea how to work out what's going on here. The odd thing about it is that according to the accounts pane the user is an admin _and_ managed by parental controls. That's not supposed to be possible.

If you've seen this .

Hundreds of Macs on AD get parental controls imposed

Thursday, July 7, 2011

Leon Lincoln has confirmed the problem of Macs on Active Directory getting parental control mysteriously applied:

I manage over 800 Macs that are bound to AD and they all show Parental Controls being applied to admin accounts. From what I can see, it is not hurting anything but it is an annoyance that I want to get fixed also. Our environment is 800-plus Macs bound to Active Directory and Jamf Casper used to manage MCX preferences and policies.

Right now I am working on cleaning up OS 10.6.8 for our next Casper Image release, and I am about to get on Apples case on this very issue as I want to clean up all potential problems before I start working on a Lion image.

If you've seen anything like this .

TIP: suggestion for fixing AD-imposed parental controls on Macs

Tuesday, July 12, 2011

Thomas Johnson has a suggestion for the problem of Active Directory imposing parental controls on large numbers of Macs. His fix is to remove certain account-level managed preferences and issuing some commands on the Macs:

I've seen some similar issues triggered by account-level managed preferences. The Account Prefs UI considers them to be parental controls for some reason - perhaps a snide developer-level commentary on the user-administrator relationship? :) In any case, it doesn't seem to actually hurt the user's administrator status, but it just prevents you from un-ticking the parental controls checkbox.

The situation can be temporarily cleared out by removing the managed preferences and deleting the corresponding local cache as well:

sudo dscl . -mcxdelete /Local/Default/Users/$user
sudo rm -rf /Library/Managed\ Preferences/$user

These will both be recreated upon login unless the account-level preferences are deleted. It's otherwise a permanent fix if the offending preferences are cleared.

If you've tried this suggestion .

Like some other readers, Jason Bush has seen the issue on a wide scale:

I've had this happen to our machines worldwide and we can't remove it. It doesn't seem to cause a problem, but it may be responsible for some local admin accounts losing all admin rights and needing to be re-imaged.

Reader says fix is a no-go for AD imposed parental controls problem

Monday, August 8, 2011

Lindsay Robertson responded to "TIP: suggestion for fixing AD-imposed parental controls on Macs" reporting this:

This idea won't work for us, we never use user-level Managed Preferences (MCX) settings, everything is set via computer lists.

If you've seen this problem

TIP: Fix for parental controls applied to Macs in AD environment

Wednesday, November 23, 2011

Lindsay Robertson in New Zealand sent us the solution to a problem she first reported this summer, a problem other users later confirmed having. The problem is that somehow, parental controls get applied to Macs in an Active Directory environment. Robertson found the problem in Mac OS X Server with managed preferences (MCX), which are configured with the Workgroup Manager application for Mac OS X Server:

I dunno if anyone else has run into this issue, but I've (finally) found a fix. Upgrading to Lion didn't fix it. I figured the problem must be in the MCX settings somehow:

Run Workgroup Manager on the local database.

Go to; Computer accounts, Overview tab, System Preferences icon and set it to Manage Always and Show All system preferences.

This brought all the dimmed system preferences back and has also prevented the 'managed' account setting reappearing on all the local accounts. Buggered if I know how the settings got implemented in the first place, but this fixes it.

If you've tried this fix


TIP: Fix for AD login issue in Snow Leopard

Monday, August 29, 2011

A reader in our forums posted a fix to a problem with Snow Leopard and Active Directory. Although the Mac appears to bind, the use would see an error message when trying to log in. The fix was to create a text file called auto_master with several lines of text.

If you've used this fix post a reply in the forum.

TIP: a Kerberos fix for OS X 10.5 and 10.6 binding to Active directory

Friday, November 11, 2011

Mehdi Mafi forwarded a fix he found for problems with Leopard and Snow Leopard binding to Active Directory:

This was taken from Dane Riley's imaging building for DeployStudio.

With Mac OS X Leopard every Mac is now running a KDC (Kerberos Distribution Center). Basically each imaged machine is using the same security certificate and hash. Deploying a single image will deploy the same KDC to every system. This [Apple] article covers how to reset the local KDC so that each system is unique. Basically, do the following:

  1. Launch Keychain Access
  2. Search for com.apple.kerberos.kdc and delete all 3 items
  3. Using Terminal type sudo rm -fr /var/db/krb5kdc
  4. After deployment, perhaps using Apple Remote Desktop to all systems, re- establish the KDC by typing sudo /usr/libexec/configureLocalKDC

If you've tried this approach with Mac OS X 10.5, 10.6, or even Lion, .

TIP: More on a kerberos fix for AD binding problems

Monday, November 14, 2011

Mehdi Mafi updated his Friday report about Mac OS X 10.6 problems binding to Active Directory:

You may want to add this. If the Mac keeps unbinding from AD (people can't log in to a Mac), here is how to fix it:

  1. Unbind it from Domain
  2. Launch Keychain Access
  3. Search for com.apple.kerberos.kdc and delete all 3 items
  4. Using Terminal type sudo rm -fr /var/db/krb5kdc
  5. Re-establish the KDC by typing sudo /usr/libexec/configureLocalKDC
  6. Bind it to domain again ( When you bind, uncheck allow authentication from any domain in the forest in: Directory Utilitiy-> Advanced Options\Administrative ) this fix the issue that sometimes it can' find AD under search space.

If you tried this


Other MacWindows Departments

| Top of Page |

This site created and maintained by
Copyright 2009-2011 John Rizzo. All rights reserved.