[the_rug]

Hi MacTroll,

Thanks for the reply.

At the moment, we have not ‘decomissioned’ (DCPROMO-ed) the Windows 2003 Server. We have simply turned it off to see what systems are still reliant on it – hence we found out the Macs were. It is still in DNS, but so is the new Windows 2008 Server.

The way Active Directory *should* work is that when one AD server is not available, the others will respond. This is clear in DNS as there are serveral ‘A Records’ for our domain name, each pointing to the AD servers. Thus, when a client cannot contact one, it should move onto the next listed in DNS.

However, I have found that many clients do not do the ’round-robin’ method of resolving DNS very well (including Windows), could this be the problem?

I don’t want to DCPROMO the Windows 2003 Server just yet, as if that does not solve the Mac problem, I am going to have a whole lab and staff Macs down until I find a resolution 😯

I suspect it is not a DNS issue but will investigate further.

I was hoping that someone who knew the insides of Directory Integration for OSX might know a simply solution for the problem.

Thanks!
The_Rug

[the_rug]

Oh, I forgot to mention:

The script cannot be run as a ‘login script’ because the context of the login script is run before the user is known, this means that the variable $1 is not known.

The script relies on this variable to know who has logged in…..

Hence it is run as a login item….

[the_rug]

Hi Mad101daN,

I think I know what you’re after, I’ve down the same myself.

I created a Bash script and it is set to run automatically as a login item.

Here’s what I did:

[size=9]#!/bin/sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin export PATH

# Make sure that the user logging in is a network user with a local home
vTOP=`dscl localhost -read /Search/Users/$1 | grep OriginalNFSHomeDirectory | cut -d ” ” -f2 | cut -d “/” -f2`
if [ “$vTOP” = “Network” ]; then

# Pull homeDir value from Active Directory
networkDir=`dscl localhost -read /Search/Users/$1 | grep OriginalHomeDirectory | cut -d “/” -f4 | cut -d “<" -f1`/`dscl localhost -read /Search/Users/$1 | grep OriginalHomeDirectory | cut -d ">” -f5 | cut -d “<" -f1` homeDir=/Volumes/$networkDir # Delete the unwanted folders (Desktop & Documents) rm -R -f "/Users/$1/Desktop" rm -R -f "/Users/$1/Documents" # Create the links to the user's network home drives ln -s "$homeDir/Mac Desktop" "/Users/$1/Desktop" ln -s "$homeDir" "/Users/$1/Documents" # Finish the loop started at the top of the script (important) fi[/size] [size=12][/size] So basically, the script checks to make sure the user has a network home drive first, then gets the homedir value, deletes the local folders 'Desktop' and 'Documents' from the user's local 'profile' (or home drive), then adds links in the profile folder to the user's network home drive. I linked the desktop as well so users could easily save things on their OSX desktop and they would be available on the network and when they login to other OSX machines. I hope this is what you wanted?!? Cheers, The_Rug

[the_rug]

Hi Yeti,

I had the same problem and it took me ages to work it out.

Turns out, it has to do with the default Kerberos settings on OSX:

Edit the file: “Macintosh HD/Library/Preferences/edu.mit.kerberos”

Under the section “libdefaults” add:
forwardable = yes
proxiable = yes

I believe it is the ‘proxiable’ portion that is the key here.

I’m not sure, but I think you also have to do the following:
i. Open a terminal on the reference workstation
ii. Type in ‘sudo pico /etc/authorization’
iii. Authenticate with the root password
iv. Press ‘Control’ & ‘W’ to start a search
v. Type in “authenticate,privileged” in the search prompt
vi. Change the text to “krb5authnoverify,privileged”. Ie. It should look like “builtin:krb5authnoverify,privileged”
vii. Press ‘Control’ & ‘X’ to exit
viii. Restart the system for the changes to apply

This tells OSX to invoke a Kerberos request when the user logs in.

Once I finally got Kerberos to work, I found a lot of accounts were being locked because of the way OSX uses the Kerberos tickets. Specifically, I was getting KRB_PRE_AUTH errors logged on the AD servers. If this is the case, let me know and I’ll post the solution to that problem as well 😀

Cheers,
The_Rug

[the_rug]

Hi Pat McCrotch,

I have setup an OSX image that does what I think you’re asking for. The problem is, it wasn’t easy.

I come from a Windows background, so I implemented the solution based on ‘trying to get OSX working the way I expect Windows to’, not the other way, so my implementation may not look very pretty:

Home Drives – once I bound OSX to AD, I made sure the following settings were set in ‘Directory Utility’:
Create Mobile Account: Unticked
Force local home directory on startup: Ticked
Use UNC path {blah blah}…..: Ticked and set to SMB
Default user shell: {your choice}

This effectively makes OSX create a local ‘profile’ (sorry, I’m a Windows boy) using the local ‘english.lproj’ template, and also connects the user’s ‘Home Dir’ specified in the user’s AD object and should place it on the dock automatically.

All that is left to do is modify the english.lproj template to include all the customisations and start-up items you want. There’s a few ‘gotchas’ in this process, especially with regards to modifying permissions on the english.lproj folder – suggest you keep a backup of that folder before messing around with it.

Specifically, I put shortcuts to network shares on the dock and a few scripts as well to automate Entourage configuration.

Hope this helps?!?

Cheers,
The_Rug

[Author]

Posts