Saturday, December 18, 2010

Bound Leopard Server not allowing SMB or AFP connections

Problem:  A 10.5.8 server was not allowing SMB or AFP connections.  The server was bound to AD but "id" commands were failing- sometimes.

Looking at the logs I saw that they were filled with launchd errors:

 com.apple.launchd[1] (org.openldap.slapd): Throttling respawn: Will start in 10

These were causing very, very poor performance and pretty much preventing Directory Service from operating; that in turn prevented any logins.

The first thing I attempted was to unbind the server but as it couldn't connect to the domain I did a Force Unbind, deleted the edu.mit.kerberos file and the Directory Services folder and restarted.  I then re-bound the server and immediately unbound: this ensured that the server's AD account would be removed.

From the unbound server I took these actions:
  • Changed the Windows role to Standalone server
  • Stopped the SMB services
  • Opened Terminal and ran "sudo –s /usr/libexec/slapd –Tt"
This returned:

could not stat config file "/etc/openldap/slapd.conf": No such file or directory (2)
slaptest: bad configuration file!
I then viewed the contents of the directory:  cd /etc/openldap/ls

There was no slapd.conf file present but there was a slapd.conf.default file so I renamed  it: "cp slapd.conf.default slapd.conf"
I then re-ran the slapd command:  "/usr/libexec/slapd –Tt" and it returned:

bdb_db_open: Warning - No DB_CONFIG file found in directory /private/var/db/openldap/openldap-data: (2)
Expect poor performance for suffix dc=my-domain,dc=com.
config file testing succeeded

Since LDAPv3 is turned off in Directory Services this shouldn't be a problem
  • Reboot 
  • Launch Server Manager
  • Change the Windows role to Domain Member
  • Start the SMB service
AFP and SMB log-ins now worked.

These steps and more info can be found here:  http://discussions.apple.com/message.jspa?messageID=10613310

Thursday, December 9, 2010

Can not log in to bound Mac using an AD account

Symptom 
A Mac that has been bound to the AD will not allow log-in from a particular AD user.  Other AD accounts are able to log-into the bound Mac and the user can log-into other computers.

This is generally a symptom of a corrupt account on the computer.  You have several options to remedy the situation.

Solutions

Scenario One:  You are migrating a local account to a domain account.  You have bound the computer and are attempting to log in for the first time using the user's AD account and you get a shaking log in or an error "you are unable to log into the user's account".  Follow these steps to create a new local account, migrate the user’s data to that account then create an AD account and migrate the data to the AD account.

  • Log in as root
  • Unbind the computer and delete the entire /Library/Preferences/Directory Service folder and the edu.mit.kerberos file
  • Restart the computer
  • Log in as root
  • Go to System Preferences/Accounts
  • Create a new local account for the user
    • Do not use the same name as the user’s AD account
    • Do not use the same name as the existing account
  • Go to Users and locate the user’s old home folder
  • Select all the folders in the old home folder and drag them into the new home folder for the account you just created.  When it prompts you select Replace All
  • Go back to the Desktop hit Shift-Apple-U to open the Utilities folder
  • Launch Terminal
  • Type cd /Users
  • Type chown –R [user name]:staff /Users/[user name]. For example:  chown –R tsmith:staff /Users/mlewis
    • Remember, you are doing the above command on the newly created home folder- the one you copied all the data into
    • Use the newly created account name for “user name”
  • Re-bind the computer
  • Log out and then back in with the user’s AD account
    • This will create a new blank profile
  • Log out and back in as root
  • Go to Users and locate the local home folder you created in a previous step (the one you moved all the data into and did a “chown” on)
  • Select all the folders in the folder and drag them into the newly create home folder (it will have the user’s AD name)  When it prompts you select Replace All
  • Go back to the Desktop hit Shift-Apple-U to open the Utilities folder
  • Launch Terminal
  • Type cd /Users
  • Type chown –R [user name]:staff /Users/[user name]. For example:  chown –R tom.smith:staff /Users/tom.smith
  • Log out and back in using the user’s AD account credentials
  • Their desktop icons should appear
  • Go to Users/[user name]/Library/Keychains and rename the login.keychain to login.keychain.old 
 
Scenario Two:  Sometimes having a UNC path to a home folder in AD prevents a user from logging in.  In this case the user can not log into any Mac but loggin into a PC works.

Open the user's AD account and go to the Profile tab.  If there is a UNC path to a home folder, remove it.  Wait for replication and attempt to log in again.

Scenario Three:  You have bound the computer and are attempting to log in for the first time using the user's AD account and you get a shaking log in or an error "you are unable to log into the user's account".

Other users can log in using their AD accounts.  Checking System Preferences/Users DOES NOT show an account for the user that is unable to log in.

It is possible that the AD profile was partially created but that the process failed somewhere along the way.   You first need to check if the profile exists on the computer even though it is not in "Users".
  • Open a Terminal window
  • Type "dscl localhost"
  • Type "cd /Local/Default/Users
  • Type "ls"
  • If the problem user's account is displayed you must remove it
To remove the account you must first download and install Apple Server Admin Tools onto the client computer.  10.6.4 admin tools can be found here:
http://support.apple.com/kb/DL1071

After you have installed Admin Tools follow these steps to remove the problem account:
  • Go to Applications/Server
  • Launch Workgroup Manager (WGM)
  • At the connection screen enter an address of "localhost" and the UID and password of the local machine administrator
  • In WGM click on the "Accounts" icon
  • Make sure you are authenticated to /Local/Default
  • Click on the single-user icon above the search menu
  •  Find the problem account in the list and click on the "Delete" icon
  •  Exit WGM and attempt to log into the machine again with the user's AD account







 

Monday, December 6, 2010

Check GPOs applied in Win7

This will export the results of the "gpresult" command to an html file:

Gpresult /H c:\temp\[machine name].html

I.g. Gprusult /H c:\temp\FRAMBW-DXP1234

Tuesday, November 2, 2010

ARD "Screen Sharing Available" problem

Many reports have come where ARD connections to remote computers display "Screen Sharing Available" next to the computer name and that although remote control and observation is possible, package install and file copies fail.

The first thing to check is to see if the firewall on the ARD console and host computers are turned off.  By default the firewall blocks all ARD connections.

Secondly, check to see if the folder /var/db/RemoteManagement exists on the client machine.  For some reason, this folder doesn't get created and it prevents proper ARD connections.

Also check A and PRT records to make sure there are no duplicate names or IPs for the client.

You can also try uninstalling and reinstalling ARD.

Uninstall instructions:
  1. Open Terminal (located in /Applications/Utilities).
  2. Delete the client pieces from /System/Library/ using the following commands in the Terminal application:
    $ sudo rm -rf /System/Library/CoreServices/Menu\ Extras/RemoteDesktop.menu
    $ sudo rm -rf /System/Library/CoreServices/RemoteManagement/
    $ sudo rm -rf /System/Library/PreferencePanes/ARDPref.prefPane
    $ sudo rm -rf /System/Library/StartupItems/RemoteDesktopAgent/



  3. Delete the client preferences from /Library/Preferences/ using the following command in the Terminal application:
    $ sudo rm /Library/Preferences/com.apple.ARDAgent.plist
    $ sudo rm /Library/Preferences/com.apple.RemoteManagement.plist



  4. Delete the client installation receipts from /Library/Receipts/ using the following command in the Terminal application:
    $ sudo rm -r /Library/Receipts/RemoteDesktopClient*
    $ sudo rm -rf /var/db/RemoteManagement/ 

    To reinstall download the latest ARD client from Apple.






Thursday, October 28, 2010

Snow Leopard Error -50 when copying to an SMB share

Symptom

Snow Leopard client copying file to SMB will get a –50 unkown error and the copying will halt. This only happens to Snow Leopard and only to SMB. Copying the same files to AFP works fine. It is also only on certain files. We can take this file to another Snow Leopard machine and reproduce it every time.

Cause

We found out that it has to do with files with resource fork. I think Snow Leopard and Leopard no longer embed resource fork into files anymore. But I am guessing these files were touched or created by older Apple OS. This explains why out of thousands of files, we only see some files with this problem. This is due to the fact that the Snow Leopard Client now defaults to using NTFS Streams rather than AppleDouble files (dot underscore files) to store the resource fork.

Solution

Turn off NTFS Streams support in Snow Leopard. You can do this on the client by running this command.

echo "[default]" | sudo tee -a /etc/nsmb.conf
echo "streams=no" | sudo tee -a /etc/nsmb.conf

Of course this would be a pain if you have to touch every clients. An easier way is to touch the share by creating a file at the root of the share called ".com.apple.smb.streams.off". As this is a hidden file, it is probably best to do this from the command line.

cd /Volumes/sharename/

touch .com.apple.smb.streams.off

No reboot is needed. Client just need to dismount and mount the share again.

Tuesday, October 19, 2010

Windows and Mac users unable to access server shares and printers

We received a report from several offices that users were unable to access server shares or print until their passwords were reset in AD.

Users were able to log into their computers and send/receive mail.

The users were receiving a "user name could not be found" error when attempting to connect to servers and the printers were showing "Unable to Connect".

The problem was that the User Principal Name (UPN) was holding old cached values. Logging into the computer using the full UPN (first.last@domain.com), restarting and logging back in with the normal AD name (first.last) resolved the issue.

This problem seemed to only affect users who had had their UPN updated recently.

Thursday, October 7, 2010

Mac Binding Fails- Advice from Apple

Apple's KB regarding binding problems and possible work-arounds involving clearing out Kerberos config files and DNS config check:

http://support.apple.com/kb/TS2691

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.

Wednesday, September 8, 2010

Using ADModify to change login and pre-2000 name

Launch ADModify using "run-as" and login using a DA account on the domain where the users you are modifying are.

For login name:  Under the Accounts tab enter the attribute:  %'givenName'%.%'sn'%

For pre-2000 name:  
  • Click on "Custom" tab
  • Put a tick in "make a customized attribute modification
  • Attribute name:  sAMAccountName
  • Value:  %'givenName'%.%'sn'%

 

Monday, August 30, 2010

Target booting an Xserver to install from another computer

We found ourselves in a situation where we were unable to install from the optical drive on an Xserver.  We used the following steps to resolve the problem:
  1. Attach a FW cable between the Xserver and another Mac (we used a Mac Book Pro)
  2. Insert the Server Install DVD into the remote computer
  3. Turn off both devices
  4. Restart the remote computer in Target Disk Mode (holding down the "T" key)
  5. Restart the Xserver holding down the Option (alt) key and select the remote install drive as the startup disk
  6. Continue with the install normally
It is VITAL that you do not target boot the Xserve onto the client: put the client into Target Disk Mode first!

After a re-IP of an Xserver, XP clients could not log in using SMB

An office moved locations and in so doing upgraded their DC to Windows Server 2008 and also change the IP of their Tiger (10.4.11) Xserve.

After completing the process, XP users were unable to log into the Xserve using SMB.  AFP connections were unaffected.

After many long nights of troubleshooting and searching through server and WireShark logs we were still no closer to a solution.  A Leopard server was built at the location to test and it initially had the exact same problem.

To get the test Leopard server to work we had to follow the steps outlined below and replace the smb.conf file with the smb.conf.template file.  After doing these steps, SMB connections to the Leopard server were successful.

During the entire process we were working with Apple and they built Tiger, Leopard and Snow Leopard servers in their environment to see if they could reproduce the problem- the could not.

Apple felt that contrary to our initial assumptions, changing to a 2008 DC did not cause the problem.  Rather the re-IP of the Tiger server broke SMB authentication.  They could not pinpoint the problem exactly but suggested we follow these steps to resolve the problem:
1. Change the role of Windows to Standalone server.  Stop the Windows service.

2. Unbind from Active Directory.

3. Run the changeip script and change the IP address in System Preferences/Network.  Restart the server.

4. Run the command "sudo changeip -checkhostname".  If everything is correct, bind the server to Active Directory.

5. Change the role of Windows to Domain Member and start the Windows service.

6. Verify the SMB shares are configured correctly (I created a new share).

7. Have XP clients connect to the 10.4 server.
Unfortunately, the problematic Tiger server wouldn't allow us to complete the tasks- failing on step 5- changing the role back to a Domain Member. 

At that point it was decided to re-build the server as a 10.5.8 Leopard server.  14 hours later, we finished the job!  There were problems with the mirrored set in the Xserver which forced us to break the RAID and install on a single physical drive.

We were finally successful at re-building the server and when we were done XP clients could connect using SMB and get single-sign-on.

One nice thing: because we only rebuild the Xserver and not the fiber channel RAIDS attached to it, all the AD file and folder permissions were retained.  This saved us a huge amount of time by not having to re-perm all the shares!


Monday, August 16, 2010

Resetting a Mac password with or without a boot disk

Boot into single user mode: hold down Command (alt) -S on startup

Follow these steps:

http://osxdaily.com/2010/08/10/forgot-mac-password-how-to-reset-mac-password/

Thursday, July 22, 2010

Friday, July 16, 2010

DHCP will not authorize after a re-IP of the server

You must first unauthorize a DHCP server scope prior to re-IPing the server.  If you do not then you will be unable to re-authorize the scope after the re-IP.

If you have already re-IPed the server without first authorizing the scope open DHCP from Admin Tools, right-click on "DHCP" and go to "Manage Authorized Servers."  Find the old DHCP server name/IP and click on "Unauthorize."

Once you have removed the old DHCP server you can authorize the re-IPed server.

Thursday, June 24, 2010

Mac Fonts

It is a good idea to remove all the fonts from ~/Library/Fonts and /Library/Fonts but leave /System/Library/Fonts alone.

Create a "My Fonts" folder, dump your fonts in there and activate when necessary.

Here are two good overviews of how the OSes handle fonts:

Leopard:  http://www.prepressure.com/fonts/basics/leopard_fonts

Snow Leopard:  http://www.prepressure.com/fonts/basics/snow-leopard-fonts

Wednesday, June 9, 2010

Mac users can not log into a bound machine continued. Network home folder problem

Bound 10.6 machines require that all users attempting to log in with AD credentials have either a correct path to an accessible home folder or have “force local home folder” ticked in Directory Utility.

Here are some things to try:

Look at the user’s account and see if they have home folders listed.  If they do, make sure they are valid and remove them if they are not.  You might simply want to remove them full stop- this has resolved problems like this in the past.  Something else to keep in mind: Snow Leopard has horrible problems connecting to SMB shares so if a user has a SMB home folder defined in their AD account it could simply failing to connect and halting the login process.

Use the work-around found in this TS article from Apple: http://support.apple.com/kb/TS3346

To force a local home folder do this:

Directory Utility > Active Directory > Show Advanced Options

Place a checkmark in "Force local home on startup disk" and uncheck "use UNC path from AD" to force a local home and ignore what's in the directory.



Friday, May 28, 2010

Enable Screen Saver Locking From the Command Line: Snow Leopard

The settings are now stored in ~/Library/Preferences/com.apple.screensaver.plist:

$ defaults read com.apple.screensaver
{
    askForPassword = 1;
    askForPasswordDelay = 5;
}
$

To turn on the screen saver lock:

defaults write com.apple.screensaver askForPassword -int 1


To turn off the screen saver lock:

defaults write com.apple.screensaver askForPassword -int 0 

Thursday, May 27, 2010

Turn on Mac screen saver password from command line (not for Snow Leopard)

Turn on the screen saver password:

defaults -currentHost write com.apple.screensaver askForPassword -int 1

Turn off Screen saver password:

defaults -currentHost write com.apple.screensaver askForPassword -int 0

Again, this doesn't work for Snow Leopard.

Friday, March 19, 2010

PC: slow login - DFS refferal to wrong DC -using dfsutil

After a re-IP two sites were experiencing slow logins.  Both sites had a "shared services" network where the DC was placed.  The shared services network is on a different VLAN than the user VLANs on the sites.

Start troubleshooting by logging into the local DC, going to Start\Run and typing \\full.domain.name.com\sysvol.  Once the sysvol window opens, right-click on any blank area and go to Properties/DFS.  The local DC should be set as the active referral ("Yes" next to the DC's name and a little tick on the name).  NOTE:  you can perform this check from any server or desktop on the site.

If the DFS referral is pointing to anything else than the local DC chances are there is a problem with Sites and Services; additionally a cleanup of the DFS cache on the DC might be necessary.
  • Make sure all the subnets at the location are in Sites and Services, INCLUDING the one the DC is in
  • Use dfsutil to clean up the DFS packets and cache
Full details of the dfsutil commands can be found HERE

On the DC run:
  • dfsutil /purgemupcache
  • dfsutil /pktflush
  • dfsutil /spcflush
  • dfsutil /pktinfo (shows which DC the DFS share is referring to)
  • dfsutil /spcinfo (shows the full path to the DFS share)
Typing "dfsutil" from the command prompt will get a list of commands.

Restarting after running these commands.

Monday, March 15, 2010

Mac User can't log in: computer bound to AD

In the ongoing saga of Mac users unable to log into a bound machine, we add this to the list:

A user could log into bound PCs but was unable to log into any bound Mac.  The user would get a shaky login screen with a cryptic message.

The problem was the user's AD account had a home folder set in their AD "profile" tab that pointed to an invalid share.

We have also seen the same problem with SMB shares full-stop.  Removing the home folder path in the AD account allowed the user to log in.

Wednesday, March 10, 2010

Entourage database and Time Machine

Time Machine and the Entourage database don’t play well together.  The problem most people have is that their Entourage profile is a massive, monolithic database and even opening Entourage causes Time Machine to back up the entire database not just the changes.  Normally the advice is to manually copy the user profile every once and a while and not let Time Machine back it up unless you have an infinite amount of disk space.

You can also have problems because even if all your Office apps are closed the database daemon is still running and this can lead to corrupt database backups.  Before you backup the Office database you can run this command:

tell application "Microsoft Database Daemon" to quit

And after you are done you can do restart or run this command:

tell application "Microsoft Database Daemon" to launch

PC slow login- Sites and Services correct but incorrect SRV record

A site that had recently been re-IPed was complaining about slow logins on their PCs- it could take a user up to 15 minutes to log in.

Sites and Services was setup correctly with the proper subnet and DC assigned to the site.

We found that there was an erroneous entry in DNS which was causing the machines to use the wrong DC for authentication.  The entry was found here:

Forward Lookup Zones
[our domain]
DomainDnsZones
_sites
[site name]
_tcp

There were two _ldap entries in this location.  One pointing to the correct DC and one to an incorrect DC.  Removing the incorrect record resolved the issue.

Note:  it is a good idea to check all the Sites entries in DNS to make sure that there are not other erroneous _ldap entries

Friday, February 5, 2010

Computer name not appearing in DHCP lease

We were seeing a problem where some DHCP leases were not showing the computer name.  None of these machines with blank lease names would show up in DNS.

It turned out that each of the machines with blank DHCP lease names were Macs and they had different sharing names than the computer names there were bound to the AD with.

The solution was to make the sharing name the same as the AD computer name.  As soon as this was done and the computer was restarted the machine appeared in DNS and the DHCP lease had the proper name associated with it.