Login hooks with AD users, systems prior to 10.10

[lkerwin]

Hello,

Was wondering if anyone could please help. I am currently in the process of testing login hooks to mount shares within our AD test environment. We are using a bash script with a profile, to run a basic Apple Script command, this mounts the share but fails when launched as a user.

sudo -u $3 osascript -e 'mount volume "afp://server/share"'

This seems to work with systems prior to 10.10, but just sits on the login window with newer systems. We can see the process for osascript, when the process is killed the desktop appears. It seems like Apple have limited the use of Apple Script, but works fine as a root user.

Any help would be much appreciated.

[mikeh]

I've been thinking about this most of the day, and I can't think of a good reason why it doesn't work on 10.10+ but does in prior versions. Almost every idea I've had - for instance, 'sudo -u $3' has no meaning in a LoginHook.sh file - fails to explain to me why there are different behaviors in different OS X versions.

I think more detail about exactly how this command is being called is necessary. Is it really in a LoginHook.sh file? Invoked by a policy triggered by login? Invoked by a ConfigurationProfile? As many details as you can provide will be helpful.

At minimum, though, I would remove the "sudo -u $3" components and see what happens. My only reasonable hunch is that there are indeed new restrictions on the use of sudo in newer OS's, but I certainly cannot explain what the actual restrictions might be.

[Look]

I use something along the lines of this in a script from Casper at login and it works fine.
It seems when called from the Casper login trigger and using Finder it mounts it as the currently logged in user.
The only other thing is that you need to wait a while (say 30 seconds) before attempting to login to ensure Finder is up and running, you might find this is actually the issue with your current command as well, it might be utilising something that hasn't yet been initialised for the logging in user.

osascript<<END
tell application "Finder"
mount volume "$True_Path"
end tell
END

[lkerwin]

We are desperate for a solution to mount shares reliably within our AD environment. The biggest problem we currently have, is we are unable to use the server path on the AD account as this is reserved for our PC network. As a result we are having to query this information with a login script, to mount the users home directories that are hosted on Apple servers. The login script also redirects the local home folder to the network, that works really well.

We have tried login hooks, launch agents, Apple Scripts but nothing seems to work reliably. If we could use the AD plugin this would probably solve most of our issues as shares are mounted before the finder appears. From our testing, the login hook would seem the best approach but not sure how to get around the user issue.

We have also tested login hooks manually, bypassing the JSS using $1 in the script to return the logged in user but still fails with newer systems.

Much appreciated for the responses.

Regards.

[bentoms]

@lkerwin I'be been using this since 10.6 (so still working on 10.11).

When you say "if we could use the AD plugin" does this mean the Macs are not bound & the clients have local accounts?

[Look]

Oh sorry thought about this more, what you need to do to stop it sticking on the login windows is seperate it away to a different process like thus:

(

All
the other code
goes here

) &

It will allow the script to end and the login to continue, with everything between the (brackets) continueing in the background, I'd throw a short sleep in there at the start to as it seems 10.10 and 10.11 need a bit of time before they are ready to mount drives as the user.

[lkerwin]

The Macs are all bound to AD, but we are unable to use the home path on the account that would usually auto mount the shares, as a result the network shares have to be mounted via a script at login.

[lkerwin]

The script works if we run as root, but no shares are displayed on the desktop, although we can see these in the terminal as root. We are only having the problem when we change the line in our script to run as a user "sudo -u $1 command".

Are you saying your method with brackets would fix the problem when users login?.

[Look]

Couple of things.

The brackets I described are for when a script is holding up the login process for a script run from Casper by seperating it away to another process, not normally neccesary if your going to do it as a LaunchAgent for example.
If you get osascript to tell the Finder to mount the volume instead of directly it generally does it as the current user and you don't need to use the sudo -u to tell it to do it as the user (or at least that is the behaviour I am getting.
Are you planning to do it as a LaunchAgent or from Casper directly on the login trigger?
Is the path stored in some other AD value?

For what it's worth here is my current general AD bound drive mounting script for both shared and home drives, it defaults to SMBHome in as stored in AD when nothing is passed to it. I run them off the login trigger (and Self Service) and use the policy scoping to determine what users they run for.
Perhaps you can pull what you need from there to achieve what your after.

#!/bin/bash
#2016 Version Samuel Look
#All care no responsibility
#Mounts the requested share if it doesn't already exist if left blank it will attempt to mount AD SMBhome
#Accepts shares in the form smb://server/share
#Intended to be run as a Login policy from Casper on AD bound machines only and has only been tested in this context.

##### Start seperate process #####
(

##### SUBROUTINES #####

Share_Path_Valid() {
if [[ -z "$Share_Path" ]]; then
Machine_Domain=$(dscl /Active Directory/ -read . SubNodes | awk '{print $2}')
Share_Path="$(dscl "/Active Directory/$Machine_Domain/All Domains" -read /Users/$Current_User SMBHome | awk '!/is not valid/' | sed -e 's/SMBHome: /smb:/g' -e 's/\///g')"
fi
if [[ "$Share_Path" ]]; then
echo "$(date "+%H:%M:%S") Share check PASS $Share_Path"
return 0
else
echo "$(date "+%H:%M:%S") Share check FAIL"
return 1
fi
}

#####

User_Ready() {
Loop_End=$((SECONDS + 60))
while [[ -z "$Current_User" ]] && [[ $SECONDS -lt $Loop_End ]]; do
sleep 5
Current_User=$(stat -f%Su /dev/console)
done
if [[ "$Current_User" ]]; then
echo "$(date "+%H:%M:%S") User check PASS $Current_User"
return 0
else
echo "$(date "+%H:%M:%S") User check FAIL"
return 1
fi
}

#####

Finder_Ready() {
Loop_End=$((SECONDS + 60))
while [[ -z "$(ps -c -u $Current_User | awk /Finder/)" ]] && [[ $SECONDS -lt $Loop_End ]]; do
sleep 5
done
if [[ "$(ps -c -u $Current_User | awk /Finder/)" ]]; then
sleep 1
echo "$(date "+%H:%M:%S") Finder check PASS"
return 0
else
echo "$(date "+%H:%M:%S") Finder check FAIL"
return 1
fi
}

#####

Not_Mounted() {
Share_Name="$(echo $Share_Path | awk -F"/" '{print $NF}')"
if [[ -z "$(mount | awk '/'$Current_User'/ && //'$Share_Name' /')" ]]; then
echo "$(date "+%H:%M:%S") Mount check PASS $Share_Name"
return 0
else
echo "$(date "+%H:%M:%S") Mount check FAIL"
return 1
fi
}

#####

Mount_Drive() {
True_Path=$(echo $Share_Path | sed 's//////'$Current_User'@/g')
echo "$(date "+%H:%M:%S") Attempting to mount $True_Path"
osascript<<END
tell application "Finder"
mount volume "$True_Path"
end tell
END
}

##### START #####

Share_Path=$4
if User_Ready && Finder_Ready && Share_Path_Valid && Not_Mounted; then
sleep 10
Mount_Drive
else
Echo "$(date "+%H:%M:%S") Conditions not met to attempt drive mounting"
fi

##### End seperate process #####
) &

##### FIN #####

[lkerwin]

We have been experimenting with the help of your script, and have now managed to get the shares mounted as a user with a login hook. The code below will simply mount our shares for the current logged in user, that seems to be what we were looking for.

(
sudo -u $1 osascript -e 'mount volume "afp://'$Server'/'$Share'/"'
) &

I would have preferred using the "mount_afp" command but doesn't seem to work, I'm guessing this has issues with Kerberos, although "mount_smbfs" seems to work but doesn't work with network disk quotas.

We have previously tested this but I'm guessing we were either missing the "&" or the "sudo" command. We can now look at creating a script to suite our needs.

Many thanks for your time and much appreciated help.

[lkerwin]

Hello,

Just a quick query regarding your script, I'm guessing you are running everything as root and not querying anything for the actual user logging in ?.

Regards.

[Look]

Yes it's just being run on the login trigger, I do however check there is actually a user logged in and wait until there is a Finder to make the mount call to mount. If your looking to simplify you can simply wait for 30 seconds or so.
Because it is making effectively a UI call to mount the share it happens as the logged in user anyway.
I do append the logged in user to the mount ie: user@server/share thats what this command is doing.

True_Path=$(echo $Share_Path | sed 's//////'$Current_User'@/g')

Just makes it easier when looking at the output of a mount command asit's immediately obvious who the share is intended for if there are multiple accounts logged in.

I probably said it earlier but one of the reasons I much prefer this method is because of the cleanup afterwards, if you do your mounting manually is mount_afp mount_smbfs etc... then you basically have manually clean up things like mount points etc... afterwards, If you tell the Finder to do it all that is taken care of automatically if the user logs out for example. It also seems to cleanly deal with who has rights etc... as well.

[lkerwin]

I did have a feeling the True_Path was doing some query for the current user, just wanted to double check. As we are unable to query the home paths from the AD account, we are having to mount our shares based on staff/student depending on the site. This method seems to work really well, and we also redirect the local home folders to network home links (documents, pictures etc..)

As you say, the osascript method to mount shares is a lot better as I find the mount_afp a little buggy, and doesn't seem to work with kerberos properly. In the early days of 10.6 we used this method that worked fine but, not as reliable with newer systems.