Apple IOS 10.6 domain bind problems - This computer is unable to access the domain controller for an unknown reason

We have had a number of Apple IOS 10.6 machines lose connectivity with the domain. This manifests itself as users not being able to login to the computer, the screen simply just shakes and doesn't allow the login.

In the past we have simply unbind the machine from the domain, then rebind the machine, problem solved. Unfortunately this time it was not as simple and we got a very generic error message that read "This computer is unable to access the domain controller for an unknown reason", great, that doesn't sound good.

Fortunately there are some more detailed logs we can look at, but first we need to enable the debug logging to ensure we capture all the important details of the failure.


Enabling the directory services debug logs

1. Open a terminal window

2. Elevate to root privledges by typing

sudo su root

3. Type the following commands

killall -USR1 DirectoryService

tail -f /Library/Logs/DirectoryService/DirectoryService.debug.log

Now the debug logging is enabled, and the tail -f command follows the log to display the latest information live on the screen.



Detecting the problem

When we put our Directory Service into debug logging and inspected the logs, we found the following errors straight after attempting to bind the computer to the domain.

Active Directory:       Password verify for administrator@TEST.INTERNAL failed with error -1765328230
Client: Directory Utilit, PID: 222, API: dsDoPlugInCustomCall(), Active Directory Used : DAR : Node Ref = 33556364 : Request Code = 84 : Result co$
Plug-in call "dsDoPlugInCustomCall()" failed with error = -14090.
Port: 20831 Call: dsDoPlugInCustomCall() == -14090

What didn't help resolve the problem

• Deleting the computer account in active directory, then unbinding/rebinding
• Unbinding and rebinding to the domain
• Recreating a fresh computer account in active directory and then rebinding
• Ensuring the IP/Host lined up correctly with the domain DNS entries
• Restoring a previous backup (obviously the computer password had changed in the previous backup, but restoring the backup then rebinding the machine to the domain also failed)

Fixing the problem

After doing some research I found a number of people that were experiencing the same issue and fortunately the fix is fairly easy, but hidden deep! The Kerberos config is located in /var/db/dslocal/nodes/Default/config/ and by deleting these configs, we can clear out any problematic settings and regenerated them.


1. If your system is still bound to active directory unbind it. This can be done in the Directory Utility, then clicking on directory services, and unbinding active directory.

2. Open a Terminal window

3. Elevate to root privledges by typing

sudo su root

4. Delete the Kerberos config, you can do this by typing.

Rm -f /var/db/dslocal/nodes/Default/config/Kerberos*

5. Reboot

6. Rebind to the domain. Again this is located in the Directory Utility.


This is a relatively easy fix, but without knowing exactly where to look, it can take a long time to find!

Apple IOS 10.6 SSO printing with Active Directory

Integrating Apple desktops into a windows active directory infrastructure can be extremely hard and one of the most difficult aspects is enabling single sign on (SSO). In a windows world nearly all services are single sign on and it can be inconvenient and annoying for users to have to continually enter their password.

I came across difficulties when I started to map network printers on an IOS 10.6 machine. When the printer authentication dialog appeared, the username field was already populated, but instead of being populated with the username it was populated with the users real name. This meant on almost every occassion when the popup appeared, the user left the username field alone and just entered their password resulting in a failure to print and lots of support calls to IT. The answer lies in a very simple switch we can use in combination with the scutil tool.


1. Open a terminal


2. Type the following to elevate your privileges to root.

sudo su root

3. We need to set the hostname of the system to the FQDN (fully qualified domain name), replace blah.domain.com with your actual FQDN, for example.

scutil --set HostName blah.domain.com

4. Next get a list of the printer queue names by typing the following.

lpstat -v

The list is shown as below.

sh-3.2# lpstat -v
device for PRINTQUEUE001_LibraryStudent_Kyocera400ci: smb://PRINTQUEUE.blah.internal/LibraryStudent-Kyocera400ci
device for PRINTQUEUE_LibraryStudent_Kyocera400ci:: ///dev/null

The printer queue name in this example is PRINTQUEUE_LibraryStudent_Kyocera400ci



5. Now take the printer queue name(s) and run the following command, replacing the "PRINTQUEUE_LibraryStudent_Kyocera400ci" with your queue name. You need to repeat the process for every printer queue for which you want to enable SSO.

 

lpadmin -p PRINTQUEUE_LibraryStudent_Kyocera400ci -o auth-info-required=negotiate

It really is as easy as that, now the next time your users go to print to any of those Active Directory printer queues you have enabled SSO on, they will not even be prompted.

home folders being renamed to "My Documents" - desktop.ini woes

Those admins that have moved from XP to Windows Vista or 7 have probably gone through the desktop.ini woes.

Desktop.ini is the medium in which Microsoft use to give a directory its custom icon or name. For example the My Documents folder has it's custom icon by a reference in the desktop.ini file. Most of the time this works perfectly, but when you are redirecting My Documents from the local location to a network share this can cause problems, especially in education.

We have a requirement for a number of staff members to be able to look at users home directories and view the contents inside. This is easy when the directories are in username format, but when the desktop.ini comes along, it "virtually" renames the folder to "My Documents" and gives it the custom icon.

So the home directories that you create like this.. (see below)

Are changed to this format as soon as a user logs into a computer... (see below)

Microsoft have been kind enough to include a nice fix in their Server 2008 R2 product, that fix is available in the "File Screening Management" functionality provided by File Server Resource Manager.

And the fix...

1. Open "File Server Resource Manager" on the file server that is hosting your home shares.

2. Select "File Screening Management"








3. Select "File Screen templates"

4. Then "Create File Screen Template..."


5. Give the template a name, desktop.ini

6. Set the "Screening Type" to "Active screening

7. Create a new "Maintain file groups", name is desktop.ini and add desktop.ini to files to include, click OK

8. Tick "desktop.ini" as your file groups to block, then click OK

9. Now we need to use our newly created template, to block desktop.ini from creating any files on our home shares folder. Click "File Screens" and then "Create File Screen..."

10. Enter your home share local file path as the "File screen path" and select your desktop.ini template under "Derive properties from this file screen template"

 11. Click create, now desktop.ini is blocked from ever recreating itself in your home share directory.

Remember if you are using DFS you will need to repeat this procedure on each of your DFS file servers. You will also need to cleanup the existing desktop.ini files that have already found their way into users home folders.