Due to SOX all our macintosh laptops, workstation and servers are
required to authenticate against our AD domain and our users has to
change their passwords regularly.
Everything has been working fine in 10.4: The AD login additionally
gives our users single signon to fileserveres in our datacenter;
smb(win2k3), afp(ExtremeZIP 4.22 or 10.4.x Server).
We are not running a managed environment but we are able to apply
settings to the clients using an ARD task-server and custom build
dummy pkg's witch are only running scripts.
The only problems we currently have with 10.4 are:
Sometimes a local cached account is out of sync with the AD domain.
This issue is easily fixed by running MCXCacher -f on the client.
Laptops which has been connected from a different site (We have a
multiple domain forrest with multiple domain controllers in each
domain) occasionally try to talk to a domain controller witch can't be
accessed due to firewall rules.
The quick fix is to edit edu.mit.kerberos and reenter the FQDN of the
accessible domain controllers of the users primary site.
If the issue affects a user often i tend to turn off the automatically
update of edu.mit.kerberos by deleting the appropriate commented lines
in edu.mit.kerberos (line 3 and 4).
All in all, issues witch are pretty easy for us in the IT department
to fix since those issues more or less only affects our laptops.
However in a very near future we wont be able to buy new Macintosh's
able to run 10.4. I'm currently the only one running 10.5 in our
organization (in order to get familiar with 10.5 and the issues we can
expect in our AD dominated environment)
The first thing i've noticed is that 10.5's afp/smb kerberos
implementation is crappy. Even though the user has a valid ticket, the
user need to authenticate with kerberos to get a any principle in the
already authenticated realm. Secondly the users can save their
kerberos password in their keychain and are offered to do so by
default. I know that i can disable that particular function pr user
basis on the client.
I can se us spending a lot of time locking up user accounts due to to
the kerberos client implementation - and a lot of annoyed users asking
questions as "why do i have to write my password all the time"?
Secondly our license management solution, HP LMS, is dependent on
single sign-on to a share. Of course we can disable authentication
against that particular share, but that means that we will have a
harder time tracking faulty LMS clients since we can't easily se witch
user a faulty data batch came from.
The kerberos issue and loss of single sign-on also affects
OpenDirectory installations around 10.3 and 10.4 server - i' haven got
hands on experience with 10.5 server yet.
From experience i know that upgrading a 10.4 client to 10.5 while
bound to AD is a bad idea. However since we are not planing mass
deployment this is not a big issue.
Binding 10.5.1 client is also tricky but after a few tries it seems to
work. However clients bound to the domain seems to stop talking to the
domain after only a few days or after being disconnected from the
domain. Sometimes they also lose the ability to recognize the REALM
even though nothing in edu.mit.kerberos has been changed.
So far haven't been able get it to talk to the domain again (in 10.4
MCXCacher -f did the trick) with forcing an un-bind deleting the local
cached user(s) and rebind the client. This brings me to my question:
What has replaced the mcxd.app and the accompanied tools like MCXCacher?
I've tried dropping in to a console and restart DirectroryService and
in 1 of 3 times it will reestablish the contact to our domain
controllers but not all the time.
Any ideas what to look for? Or did apple just screw large scale
companies dependent on Active Directory? I can imagine that the issues
i'm experiencing with 10.5 also applies to OpenDirectory - especially
the loss of single sign-on
--
Morten Reippuert Knudsen
