Prev: Numbers, way to transpose columns and rows?
Next: Mobile accounts in AD, any fixed duration?
From: Alan Baker on 3 Aug 2010 22:35
I'm trying to run down a strange issue I'm having at one of my
clients.

It's a large shop with an Active Directory setup to which the Macs are
connected and most everything is working properly. Users log on with
their AD credentials and their home folders get mounted and they can
access additional shared volumes without needing to enter their
passwords again...

except for some situation. Provided they connect to their additional
shared volumes via Command-K, and provide the Mac OS X Server's name
in lower-case letters, the connection proceeds with a kerberized
connection which takes them directly to the list of available shares
on that volume. If they capitalize the server's name, then the
kerberos connection fails and they are required to re-enter their name
and password, and -- which is far worse:

Any sidebar entries created from a share's folders or any login item
created to remount that volume at login will do the same, EVEN AFTER
YOU RECREATE THEM WITH THE SERVER CONNECTED WITH A KERBERIZED PROCESS.

So my question is: how do I dig out the data to which the system is
obviously still referring? Does anyone know where the data would be
cached that causes the sidebar and login entries to invoke the server
by it's all caps name?

I think it has something to do with the alias data that both the
sidebar and login item plists use to store information about the
location of the items, but looking at it in PlistPro only gives a
simple path such as "/Volumes/sharename/folderinsidebar" without any
indication of where the original is actually located.

Any thoughts?
 | 
Pages: 1
Prev: Numbers, way to transpose columns and rows?
Next: Mobile accounts in AD, any fixed duration?