Showing posts with label "Snow Leopard". Show all posts
Showing posts with label "Snow Leopard". Show all posts

Thursday, March 8, 2012

Slow Login on Snow Leopard Clients Bound to AD

We have received several reports that Snow Leopard clients that are bound to AD are experiencing very slow logins- up to five minutes before the desktop would appear.

One fix is to remove Active Directory/All Domains from the Authentication tab in Directory Services.  Once this is done the login is very fast.

The drawback is that no other user will be able to log into the computer using their AD credentials.

AD password changes done via the login screen or System Preferences/Users/Change Password continue to work.

Full details can be found on Tech Smog.

Friday, December 23, 2011

Lion clients unable to connect to Snow Leopard server

If you are attempting to connect from a bound Lion client to a bound Snow Leopard server you must use the FQDN for the server. 

For example:  myserver.test.network.com

If you do not you may receive an error that says "The version of the server you are trying to connect to is not supproted.  Please contact your system administrator to resolve the problem."

Also check what authentication method you are using.
  • Open Server Manager
  • Highlight "AFP"
  • Click on the "Access" tab
  • Change "Authentication" to "Any Method"
Attempt to connect from at Lion client using the FQDN of the server.

Note: changing the authentication to Any Method can possibly break single-sign-on for Snow Leopard client.  If this happens change the authentication to "Kerberos".  Lion clients should still be able to access the server.

Tuesday, May 10, 2011

OS X Server: users can not connect to SMB or AFP shares

We have been troubleshooting several reports from offices with bound OS X servers where Mac and PC clients are unable to connect to shares using AFP or SMB.  Additionally these offices have reported that Macs will randomly drop their AFP connections to the OS X server.

When the connection problem occurs often times the server shares will display generic ACL GUIDs: a series of numbers and letters instead of the group name.   In cases such as these restarting Directory Services generally resolves the problem- at least temporarily:

sudo /usr/bin/killall DirectoryService

Other times the GUIDs display normally but the connection problems still persist.  In these cases two things are suggested:
  1. Nest AD users into local groups and then use the local groups to populate the ACLs
  2. Flush the group membership cache by running this command:  
sudo dsmemberutil flushcache

Generally these problems occur most often on Leopard servers- Snow Leopard servers have improved group membership caching.

Wednesday, October 6, 2010

Snow Leopard (10.6) can not connect to server using SMB: RESOLVED

Problem: AD bound 10.6.x Macs were experiencing problems connecting to SMB shares on Windows servers.  Users could not connect to the shares, or it would take several minutes to open/browse folders.

Cause:   It was found that the issue happens when there is a folder or file on the share for which the security list includes an “Unknown SID”. When listing the content of the share, the OS X Directory Service plugin attempts to resolve all SIDs to AD objects. In this case, the plugin encounters a “Unknown SID” and expends 60 seconds attempting to resolve the SID. Once 60-second timeout is reached, the plugin skips the entry and will list the share contents. Now, if there are multiple files or folders of “Unknown SIDs”, the time for listing the content will multiply base on how many of these “Unknown SIDs” on there thus explaining the different delay time users are experiencing.

Resolution:  
Test indicates that once these “Unknown SIDs” are removed from the affected file/folder, the speed of SMB will return to normal. The mount and content listing of the share will take seconds instead of minutes.

Apple will take the finding back to their product engineering to determine how they might be able to mitigate the timeout issue from OS X.

The problem of resolving this issue for server administrators is that it is not practical to identify these “Unknown SIDs” and remove them manually. After some research, it seems that Microsoft has a tool to do this.

SUBINACL - Display or modify Access Control Entries (ACEs) for file and folder Permissions, Ownership and Domain.


Download the MSI and install it to your file server. You can then run it using the following syntax. It will removed all the “Unknown SIDs” from the files and folders you specify.

subinacl /subdirectories X:\* /cleandeletedsidsfrom=IPGNA

This will clean out all “Unknown SIDs” from the path you specify and all the directories below that. You can also use a /TESTMODE switch to test it out. It will run the command and show you the result without actually modifying anything. It is recommended that you run it under testmode once.