|
|
 |
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
More on Snow Leopard Active Directory woes
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
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.
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:
- Remove the Home folder path specified in Active Directory for the user.
- Log in to the Mac OS X v10.6 client.
- Create the mobile account when prompted.
- 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
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
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
OS X 10.6 Word can't save on Win-based home directory; scanner fix | Top of Page |
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
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
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
Note: there is also a discussion about this topic on our Snow Leopard File Sharing Tips and Reports page.
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
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
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")
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
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
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.
Apple, MS, say Win 7 client can't join OS X Server PDC Domain
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
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.
|
|
|
