[Server 10.3] My experiences and troubles

mvdheuvel

Registered
Brace yourself, this will take some time. This is all from memory, so there might be some glitches here and there.

* invites you to take a seat *

It all started about 2 weeks ago. Finally, the new G5 and Mac OS X Server version 10.3 arrived. I was very excited: a new type of processor and a new version of the operating system, hopefully better than version 10.1.
I proceeded to install Server 10.3 and followed the instructions presented on the screen, filling in appropriate fields. One of the sections I was interested in, was the Open Directory service. Ah yes, this could really benefit our organisation. I chose the role "Open Directory Master" and finished the rest of the setup process.

Once I logged in, I immediately took a look at "Server Admin". I enabled a few additional services and took a look at the "Open Directory" service. First of all, in the pane "Overview", it stated that the "LDAP Server" service and the "KDC" service both were not running. Hhmm, there's something not right here. I proceeded to go to the "Settings" > "General" pane. I was surprised when I saw the role for the server was currently "Standalone Server". That's not what I chose earlier. So, I switched back to "Open Direcotry Master". Again, I filled in all of the fields. So far, so good I thought. I can't remember if the service "LDAP Server" was now running, but I do know that the "KDC" service was not running.

I opened the "Workgroup Manager" and immediately was confronted with a dialog stating I was working in a directory which was not visible to the network. Fine by me, I clicked "OK". I then clicked the globe icon in the top left corner to choose the LDAP directory. To my surprise I couldn't authenticate to the directory. After about 30 minutes of pondering on what I might have done wrong, I decided to get some help: Apple discussions, Google, MacOSX.com. I was in luck: apparently I was not the only one with the authentication problem. Solution to the problem: during the initial setup ALWAYS choose "Standalone Server" as role for the server (Apple discussion). Only change to "Open Directory Master" when in "Server Admin". If you do choose "Open Directory Master" during initial setup, swith back to "Standalone Server", delete the LDAP database (/var/db/openldap/openldap-data), reboot to be sure and then choose "Open Direcotry Master" as role in the "Open Directory" service.

But, this is not all. No, now the "KDC" service is still not running. Normally, if the initial setup would work, the "KDC" service should automatically start if the "Open Directory Master" role is chosen. But somehow, if you choose this role later on, the "KDC" service does not get started. Have no fear, there is a solution: AFP548.com (AFP548.com). Follow the instructions and you will have a running "KDC" server.


Don't sit back though! This is not where the Apple Server experience starts! Oh no, there is more. You see, there is no problem whatsoever to setup 10.2 or 10.3 clients to authenticate to the LDAP directory with Kerberos. But at that point, another problem occurs. The sharepoints on the server are not correctly passed through to the clients (all involved clients are 10.3):
  1. Some of the shares available to a particular group of users, are not shown to a user on a client. For example, I have a user "mvdh", who is part of the group "sysadmin". This group has access to the network shares: "Installation", "Backup" and "Stuff". I log into a machine using this account, go to "Network" > "Local" > "Server1" > "Connect". It has happened that I only get to see 2 of the 3 shares. And when I do the same thing on another client, I do get to see all 3 shares.
  2. Clicking the "Connect" button doesn't visually trigger a refresh of the window, resulting in showing the available shares. I need to close and open a new window 2 or 3 times before I see the shares.
  3. This problem is somewhat the same as problem number 1. Changes in the available shares of a particular user, don't get propagated to the client. Example: I have a user "mvdh", who is part of the group "sysadmin". This group has access to the network shares: "Installation", "Backup" and "Stuff". I connect to the server and see all 3 shares. I then logout of the client with the user and change the available shares for this group; let's say I remove "Stuff" from the shares available to the group "sysadmin". I then log into a client as user "mvdh" and connect to the server. I still get to see the old share "Stuff" in "Network" > "Local" > "Server1". No interaction is possible with this share, a dialog appears reporting this (I can't remember exact dialog). I then logout again and re-add the share "Stuff" to the group. I, again, log into a client and connect to the server. Now, there are 2 shares "Stuff" visible: One "Stuff" (fodler icon) and one "Stuff-1" (network alias icon).
My question is: is some kind of history recorded client-side, which remembers any previous visible shares? If so, is there a way to remove this history and start off with a clean slate?

Further, is there someone else out there with similar problems, or someone who knows how to solve these problems? Am I missing something in the whole setup which causes these problems?
 
I have now switched back to the local NetInfo domain on the server for controlling access to the server shares. And it seems to be working now.

I have the KDC running, but now the users are authenticating to /NetInfo/root. And the problems I had before with the client computers remembering and showing shares to which the user in the past had access, but now not anymore, are solved. The shares to which a user has access, are updated immediataly to the client in case of change of privileges on the server and the client will only see those shares to which he/ she has access now.

It seems there was a problem in my configuration concerning the updating of the user information locally to the client after for example the privileges of the user had been changed (problem 3 in my previous post). I assume the server updated the privileges, but the client didn't get a message from the server saying: "Update your locally stored user information because things have changed."

Does anyone else have this problem, the locally stored user information not being updated properly?
 
Back
Top