Network users fail to login

You likely do not have a valid NFSHomeFolder attribute defined. That is why the loginwindow shakes you off. Do this:

1: Open Workgroup Manager and go to the Workgroup Manager menu and select preferences.
2: Check the box, "Show 'all records' tab and inspector"
3: Select the user from the list
4: Press the newly visible Inspector tab at the far right
5: In the list of attributes, find the NFSHomeDirectory attribute and change the default 99 value to the location of the user's home folder (ex: /Users/shortname)
6: Save the record.
7: Attempt to log in again

Let me know if that resolves it. Hope this helps.

I'm having the same problem. It started after I had a corrupt LDAP Db and decided to start over and redo the directory master. After adding my 10 previous users back into the new WGM, they worked fine. Now any new user I add can't log in -- they get shaken off. I tried resetting teh NFSHomeDirectory of one of the new users to /Users/test1 (it was set to the default 99, and 'test1' is the user name), and I still get shaken off. Do I need to restart the service or the box for this to take effect? Is there anything else I can try?

Thanks!

The most common causes of directory login failure are:

DNS
Time
Invalid account record

Try this. Reboot the machine and at the login window, click on the text beneath Mac OS X and keep clicking it to see the status of network accounts. Are they available or not? If not, then the system is not joining the domain and your existing logins are likely cached.

Confirm that your DNS is working properly. You need to have properly working forward and reverse DNS of the server working. Next, is time. All systems should be using the same time server. A time skew of a few minutes will result in login failure. Commonly, time server is enabled on your server and you configure all your clients to get time packets from the server. This keeps all ntp traffic on the LAN and ensures a mutually trusted time source.

Beyond this, there are a number of ways to debug directory services. You can enable debug with a sudo killall -USR1 DirectoryService or by creating the file /Library/Preferences/DirectoryService/.DSLogDebugAtStart This can be done with: sudo touch /Library/Preferences/DirectoryService/.DSLogDebugAtStart Restarting the machine will enable debug logging from boot. The debug log file will be found in /Library/Logs/DirectoryService. Remove the file to turn debug logging off.

Hope this helps

Yes, it helps immensely. My bad though, as your first fix DID work. I accidentally changed the path of the default VPN user. Once I caught that and updated my test user it worked, as well has auto-updating all my other users to their correct home folder.

Last question: Any idea why OD set the users home folder initially to 99 and wouldn't let me update it via home tab under the user settings? This seems buggy to me.

Thanks for all your help. I'm now back up and running!

In OD, the default value for attributes that can not be null is 99. The NFSHomeDirectory attribute is defined not to be null. So Apple just populates the value of the attribute with the default value. This is done because home folder path is not an absolute. What I mean by that is that in some cases, like system users, you want an invalid home to prevent access. In other cases, like network home accounts, you will first need to define the automount and then select it from the home tab. In your case (and in just about every case I've worked with), you are using managed mobile accounts which store home folders on the workstation drive but reference authentication information from the server. I agree that the default local path would be nice, but because home folder can be so many different things, defining a default that doesn't work for everyone would be as bad as defining a default that works for no one except for high security issues.

Glad to have helped.

Oh, if you care, this is a difference from Tiger server. In Tiger server, the NFSHomeFolder attribute was still set at 99. However, Tiger client would not prevent login. Instead, the user would be authenticated and a folder titled 99 would be created at the root of the local hard drive (/99). Imaging the confusion on a shared system with potentially 10s of users accessing the machine. All users would be dropped into the /99 folder but only the first person that logged into the workstation would have write access. Very bad. So, compared to Tiger, even though there is confusion and no documentation about creating the home path, Leopard's denial at login window is better than Tiger's permissiveness.

Awesome info -- thanks a bunch. I did notice the 99 home folder was happening on tiger clients. Now I know why.

Thanks again.

Assuming that the server is on the LAN and not on the DMZ or WAN (directly assigned public IP address), you need to act as SOA for your own domain. This does not mean that you need to replicate your public DNS nor do you need to host DNS and be a public SOA. Leave that to whoever is maintaining your public name space. Internally, you can either use an alternate TLD (such as .org or .net) or you can create a fictional TLD like .int. Whichever the case, OS X Server is highly dependent on properly functioning DNS. Follow these basic steps to make this work (again, this assumes that your server is on a LAN and has private addressing (192.168.x.x, 10.x.x.x, 172.16.x.x):

1: Decide what name you want to call the server, for this illustration, lets say file.carawood.int
2: Open Server Admin, select the Settings gear, select the Services tab
3: Check DNS from the list and press save
4: Select DNS from the list of configurable services and press the zones tab
5: From the Add Zones popup, choose Add Primary Zone
6: In the form that appears, enter the following:
Primary zone name: carawood.int.
Nameservers: file
The other values can be filled in but based on your post, you are not dealing with mail on this server and you have only one server (zone transfers)
7: Press save to save the zone
8: This will create a zone record at the top of Server Admin. Click the reveal arrow to expose the machine record created at the time of the zone. It should be labeled file. Select it to get the edit sheet.
9: In the IP Address box, change the default value to the IP address of your server.
10: Press Save
11: Start DNS

Now that it is running with a single record, test it using these two commands in Terminal

nslookup file.carawood.int IP OFSERVER

(ex: nslookup file.carawood.int 192.168.1.10)

nslookup IP OFSERVER IP OFSERVER

(ex: nslookup 192.168.1.10 192.168.1.10)

These commands should return back proper results. Once this is working, then you can configure your machine to use this by default.

1: Open System Prefenences
2: Open the Network Preference panel
3: In the DNS field, place the IP address of your server as the primary address. Leave the public DNS servers as the 2nd and 3rd.
4: Optional: enter carawood.int as the default search path.
5: Apply

Now your server is configured to first check itself for DNS. It will now identify itself as file.carawood.int and each lookup will be successful.

Note, the example above used the .int TLD. If you decide to use .com and you have externally hosted services (web, mail, etc), you will need to create DNS records internally to map to the external systems.

And finally, you will probably also want to check if the server likes its new identity. This can be done with the following from the Terminal:

sudo changeip -checkhostname

I will wait to see your results before going further.

Hope this helps